rustaudio / audrey Goto Github PK

Since there hasn't been much movement on https://github.com/RustAudio/mp3. I could make a PR to add mp3 support via https://crates.io/crates/minimp3. Since that is a C wrapper and against the stated goal of Audrey, perhaps making it a non default feature would be acceptable. Once a production ready Rust mp3 decoder is made that can be swapped in and the feature enabled by default. The API should stay the same with the exception of the types wrapped by the Reader and Error Enums. Maybe calling the non default mp3 feature "mp3_unstable", with a README comment about that expected breakage would be enough. I don't think most users will need to access the inner values anyway.

I currently have a a Enum wrapper around Audrey and minimp3 abstracting the two in some code I'm using. The only slightly weird thing is that mp3's can change sample rate (it's apparently set per block) and maybe channels. So I'll need to extend minimp3's errors with another wrapper type in the middle, to error if those values change in the middle of a file.

I don't know whether supporting aac/m4a/mp4 is blocked on any patents etc. Just listing it here as a feature request.

As mentioned in #8, perhaps the read::Description could indicate whether the channels are interleaved or non-interleaved and this could be used by users desiring the most efficient method of reading samples.

This is a follow up to @est31's idea of providing an audio utilities crate.

@est31 I started the rustaudio/sample crate a while ago to fulfill this purpose - I'd love to get your thoughts on it!

audio already uses it to handle target sample format conversion in the read::Samples and read::Frames iterators. sample supports linear and sinc interpolation for resampling at the moment and I'd be happy to see more kinds of resampling supported if need be. It is dependency-less and only depends on rust's core library. It has a thorough suite of tests for conversions, fairly extensive documentation and I've used it in the majority of my personal audio-related rust projects with success so far. It would be great to get your thoughts on it if you get a chance 😸

It's not obvious that this library does encoding and writing of any audio formats. Is this on the roadmap? Maybe in a branch?

Would be cool to have a pure rust MP3 decoder that's permissively licensed. Couldn't find anything on crates.io, so we'd have to write our own.

While there are quite some free software decoders written in C, most of them are copylefted (LGPL or GPL).

These are the only non copyleft implementations I could find:

• fluendo decoder (available by svn co'ing this URL ) => claims to be MIT licensed, however it contains code from the ISO mp3 distribution 10, which is non free, so the MIT claim is dubious...
• http://hackage.haskell.org/package/mp3decoder => BSD like license
• Writeup about some parts of the codec: http://blog.bjrn.se/2008/10/lets-build-mp3-decoder.html

This is a big list of decoders available (most of them are either non free or copyleft): http://www.mp3-tech.org/programmer/decoding.html

I'd say we should port the haskell decoder to rust. Any volunteers?

The Quite OK Audio Format "[..] decodes audio 3x faster than Ogg-Vorbis, while offering better quality and compression" - https://qoaformat.org/

There is a reference encoder and decorer available here https://github.com/phoboslab/qoa and here is a zero-dependency rust implementation https://github.com/rafaelcaricio/qoaudio

Recently, there has been a RCE-able c implementation. With all the rust based SNES emulators around, I'm sure there is one that also has support for the SPC music format? It would be great to provide a safe alternative to the dangerous C implementations our users.

Here's the code I'm running:

let mut song_ogg = audrey::open("resources/audio/song.ogg").unwrap();
let frames: Vec<Stereo<i16>> = song_ogg.frames()
    .filter(|x| x.is_ok())
    .map(Result::unwrap)
    .map(|x: [i16; 2]| Stereo { left: x[0], right: x[1] })
    .collect();

For whatever reason, this takes more than 50 seconds to run, but song.ogg is only 3.2 MB. Am I doing something wrong?

I thought audio could be a good name for the crate, as I kind of see it as an audio equivalent of the image crate.

It seems the audio name is currently reserved, though the crate looks to be empty or at least inactive. Perhaps we can contact the owner to see if they would be at all interested in transferring the crate name to us.

Hello everyone,

I am currently planning to start an audio player project and wanted to ask what the plans of handling metadata (tags) with this library are?

This looks like a very nice collection of whats available, but I will need to handle at least reading tags
and in the long run also write tags for audio files.

Using audrey seems like a waste of time, if I still need to depend on the decoders or even other decoders (I see claxon, does not expose the internals of the VorbisComment header, like the flac crate does for example) to handle metadata.

If audrey's goal is only to de/encode samples that is totally fine, but the readme does not really tell that.

Currently, the read::Description provides:

• The number of channels via channel_count().
• The rate at which the audio is sampled per channel via sample_rate().
• The audio Format via format() as of #4.

Some other useful information might include:

• Whether the channels are interleaved or not. If we end up providing unique methods on the Reader for producing InterleavedSamples and NonInterleavedSamples, this could be a useful indicator for determining the more efficient option?
• Whether the sample is formatted as integer or floating point data.
• The bit depth per sample. Users who care highly about performance could match on this alongside the sample format to request the most efficient target Sample type when calling Reader::samples.

Here's the alac crate.

@est31 ping! These are humble beginnings, still lots to go. I thought it could be good to upload it sooner rather than later to get your thoughts and feedback on the direction of the API etc. I'll start posting some issues for todo-items I have in mind soon.

@ruuda so far this crate is 50% simply wrapping your awesome work! I thought I'd ping you in case you'd like to follow along or in case you'd be interested in contributing at any point. The API design is largely inspired by your design in hound and claxon - it would be great to get your thoughts if you get a chance. Would be more than happy to invite you as an admin if you felt inclined!

@tomaka I thought you might be interested in using this for rodio, perhaps as a replacement the decoder module? I think you are also still an admin of rustaudio, so feel free to open issues/PRs or give your thoughts on the direction of the crate if you are interested at all 👍

@mitchmindtree could we get a 0.2 release?

Also, can you add me as owner of the crate on crates.io? Thanks :)

Is anyone planning to implement the write functionality?

This library seems incredibly useful to do audio file conversion in a web client through Wasm.

Is there some documentation about this library somewhere?

In particular, I would need a way to convert a WAV buffer to AAC to pass it back to JavaScript.

Thanks!

Audrey 0.2.0 depends on sample 0.9.1. This crate has been discontinued and is not called dasp.

When using nightly Audrey breaks because of sample:

error[E0282]: type annotations needed
  --> /Users/moritz/.cargo/registry/src/github.com-1ecc6299db9ec823/sample-0.9.1/src/window.rs:73:41
   |
73 |         let v = phase.to_float_sample().to_sample() * PI_2;
   |                                         ^^^^^^^^^ cannot infer type for type parameter `S` declared on the associated function `to_sample`
   |
help: consider specifying the type argument in the method call
   |
73 |         let v = phase.to_float_sample().to_sample::<S>() * PI_2;
   |                                                  ^^^^^

This happens also on master which depends on sample 0.10.

dasp does build with nightly.