These files exhibit mismatches compared to ffmpeg:

1.25170898 01 - Give It Away (In Progress).flac 1.93112183 05 - Киберпанк.flac 1.59304810 06. The Sunshine.flac 1.98730469 03 Roll Us A Giant.flac 1.72723389 10. The Parts.flac 1.08828735 07. The Grocery.flac 0.08523428 04- The Hours - Arr. Michael Riesman - Morning Passages.flac 1.66995239 16. Olivia's Doom (Chad Mossholder Remix).flac 1.92807007 09 - Путь прост.flac 1.92960131 40. Stumpy.flac 1.99769855 3-Blue Jeans.flac 1.92474365 Robert Rich - Echo of Small Things.flac

More over, one of the files triggers an error:

ERROR symphonia_core::probe > reached probe limit of 1048576 bytes.Test interrupted by error: unsupported feature: core (probe): no suitable reader found 01. You Are Light (feat. Felicia Farerre).flac

Hi! This PR adds an initial support for matroska and webm containers that is intended to close #63. It is far from complete, but I decided to share what I have so far to get some feedback.

Removes the last use of unsafe from symphonia.

Obligatory disclaimer that while this compiles fine and cargo test passes, I'm not sure how to actually test these changes on actual audio since symphonia-play doesn't like my computer's audio devices for some reason, so im blind to if this actually broke something.

Closes https://github.com/pdeljanov/Symphonia/issues/38

Data link

The high-delta mismatches are likely simply misaligned, although I haven't been able to confirm that.

I have excluded files with max delta below 0.001.

Tested on commit 16497ee5fb0d2f00287ba3444c52b22bc4debdae

First of all, thanks for making and sharing this library, I'm very happy to have discovered it, kudos!

I've noticed some behaviour that I don't understand while decoding some .wav files (I haven't checked all of their formats, but typically they're stereo 16bit, 44.1k, PCM).

Is it expected that the sum of all decoded AudioBufferRef frame counts should match the n_frames value defined in the track's codec params? I'm finding that in the last decoded packet, there are sometimes extra frames in the buffer, which then contain data that isn't in the file (e.g. Each buffer's frame count is 1158 through the file, then the final buffer contains 541 frames, when there are only 118 frames remaining according to the count).

I can share an example if you like but I figured I'd better check first if I'm just misunderstanding something in the API.

• Gets an immutable reference to the latest, and therefore newest, revision of the metadata.

Removes the need to pop though the revisions via a loop when all you want is the latest.

As mentioned in https://github.com/librespot-org/librespot/pull/967

I have a few mp3 files like this, where it plays the file and then plays it again. The file is 2:17, but it's played for about 4:34: Kill Paris feat. Big Gigantic & Jimi Tents - Fizzy Lifting Drink.mp3.zip

I'm guessing there's something about how it's encoded that causes Symphonia to trip up, but no idea what that could be.

Cargo.toml

[package]
name = "mp3test"
version = "0.1.0"
edition = "2018"

[dependencies]
rodio = { git = "https://github.com/RustAudio/rodio", rev = "d40551d", features = ["symphonia-mp3"] }

main.rs

use rodio::{Decoder, OutputStream, Sink};
use std::fs::File;
use std::io::BufReader;
use std::sync::mpsc::channel;
use std::sync::mpsc::TryRecvError;
use std::thread;
use std::time::{Duration, Instant};

fn main() {
    let path = "Kill Paris feat. Big Gigantic & Jimi Tents - Fizzy Lifting Drink.mp3";
    let file = File::open(path).unwrap();
    let buf = BufReader::new(file);

    let decoder = Decoder::new(buf).unwrap();

    let output_stream = OutputStream::try_default();
    let (_stream, handle) = output_stream.unwrap();
    let sink = Sink::try_new(&handle).unwrap();

    sink.append(decoder);
    let (send, recv) = channel();
    thread::spawn(move || {
        sink.set_volume(0.25);
        let start = Instant::now();
        sink.play();
        sink.sleep_until_end();
        let dur = start.elapsed().as_secs_f64();
        println!("Ended, took {:.3}s", dur);
        send.send("End").unwrap();
    });

    let start = Instant::now();
    loop {
        match recv.try_recv() {
            Ok("End") => break,
            Err(TryRecvError::Empty) => {}
            _ => panic!(),
        };
        let dur = start.elapsed().as_secs_f64();
        println!("\u{23f1}  {:.3}s", dur);
        thread::sleep(Duration::from_millis(1000));
    }
}

Move bounds checks out of the hot loop to be performed only once outside it. This should provide a modest performance boost, especially on CPUs with less powerful speculative execution.

Reduces the output of cargo asm for this function from 488 to 412 lines, when annotated with #[inline(never)] to make it easy to inspect.

This doesn't introduce any new panics - the code would have panicked anyway, now the check is simply performed once per function call outside the hot loop.

There might be a more elegant iterator-based way than .try_into().unwrap(); I haven't really looked into it.

Many other functions in this file can be given a similar treatment; this should provide a total boost of a few % in terms of performance for end-to-end decoding. This PR is meant to demonstrate the approach. I could proceed with converting the rest to this idiom, if you wish.

This, as-is, will try and fuzz all the default-enabled targets using the format guessing. This is probably good enough to not need one fuzzer target per format?

These files show max delta up to 2.0 when compared against ffmpeg with symphonia-check.

I meant to test against mpg123 as well, but on my system --ref mpg123 always results in 0 samples compared, even though mpg123 itself seems to work. I suggest you run the check against mpg123 as well and only investigate files that diverge with both decoders, because this time it's a lot of files!

Tested on commit 898ee01ff9785eff54782da85124c32d9cdadfc9 (latest as of this writing).

The files are from the Pony Music Archive corpus and should be free to redistribute. I like this corpus because it contains files produced by a wide variety of encoders. I have previously run the test on a subset of this corpus; I've pruned the files I've already reported from the archive. I have run the check on the entire corpus this time; this amounts to roughly 200Gb of MP3 (27552 individual files).

symphonia-play detects this corrupted mp3 file as stereo 22050 Hz, so it plays it back at ~4x speed. It's actually a mono 11025 Hz one, and plays correctly in VLC for example. This data was extracted from https://z0r.de/L/z0r-de_6315.swf.

There seems to be an unusually high amount of 0xFF bytes before the first actual frame, which most likely throws off sync_frame(), even though check_header() does a decent amount of sanity checking. Perhaps it should also be extended with parsing the header at any potential frame sync point, then checking whether right after the potential frame there's either the end of the data stream, or another sync sequence (frame header). This would necessitate adding a seekback buffer of (in some cases) as long as ~2.9 KiB, which should not be an issue with local file sources, but for network streams, it might add a noticeable amount of latency. It might also prevent syncing to perfectly valid frames that happen to not be directly followed by another frame... So maybe it should be a decoder option? There might be other ways to fix the synchronization of this file, but this is what's described here: https://hydrogenaud.io/index.php?topic=85125.msg747716#msg747716 If the frame (supposedly) has CRC, that could also be used instead to rule out red herring frames.

The "correct" way might be to change the sample rate and channel setup at each decoded frame as necessary, but I'm not sure if the playback machinery (of either symphonia-play, or of any embedding application) is set up for that.

For reference: https://github.com/ruffle-rs/ruffle/pull/4273, https://github.com/ruffle-rs/ruffle/pull/5231 (EDIT: The reason I'm reporting is that at the moment, https://z0r.de/6315 only has sound in Chrome, but not in Firefox, as Ruffle currently uses decodeAudioData to decode MP3 sounds, and the mandated-by-spec format sniffing in FF can't figure out that it is in fact supposed to be MP3 content, most likely due to the amount of garbage before the first frame. If only https://github.com/WebAudio/web-audio-api/issues/7 ended up being resolved...)

Some .flac files downloaded from Bandcamp have the UNSYNCEDLYRICS tag set if the artist added lyrics to a track. This PR enables Symphonia to also read this tag for lyrics metadata.

Instead of taking in MediaSourceStream, is it possible to have decoders generically take in a M: MediaSource trait instead? (Or possibly Box<dyn MediaSource>, although I prefer the generic version because of fewer pointer indirections). The reason being, the underlying MediaSource implementation may already be buffered or is entirely in-memory, causing unnecessary copy into the buffer within MediaSourceStream.

The existing MediaSourceStream can be repurposed as MediaSourceStream<M>, a buffered wrapper type over MediaSource types, so that the user can decide for themselves whether they require buffering (pay only when needed).

Trying to read music production software FL Studio's built-in sample file "FPC 1 Kick.wav" throws an Unsupported("wav: unsupported wave format") error

Sample file (rename .png to .wav):

Audacity can read this file already

Fixes: https://github.com/pdeljanov/Symphonia/issues/43

The symphonia-play example will now use libsamplerate to resample according to the default output config from Windows.

Suppose application has a fixed buffer to store every packet data, but before invoking Decoder::decode() it must invoke Packet::new() to alloc data first. That make poor performance. Is possible that add a new type PacketRef and change decode function signature to Decoder::decode(&PacketRef) ? The PacketRef look like: pub PacketRef<'a> { .. the same as Packet, data: &'a [u8], }

I tried the following added to the getting-started.rs example after probing the media source:

     if let Some(mut meta) = probed.metadata.get() {
         if let Some(latest) = meta.skip_to_latest() {
             for tag in latest.tags().iter() {
                 println!("{:?}", tag);
             }
         }
     }

It works for mp3 files with utf8 tags, but it doesn't find anything for the ones in latin-2. Adding at least a fallback encoding would be great.