0x08088405/rmp3

fast & safe no_std minimp3 wrapper

rmp3's Issues

The input buffer shouldn't be a member of the Decoder

It is very rarely that the user of the mp3 decoder could load the entire mp3 file in memory and then call the Decoder function. Ideally the next_frame function would receive the input buffer.
I was considering using this library for an embedded project. There the data would come from an SD card and the entire RAM of the device is 40k

Sample values overshoot 1.0 with float feature enabled

Hi,

First off thank you so much for rmp3, it's working very well!

This report might not be a bug, but maybe a mis-expectation on my part, but just to be sure I wanted to clarify this:

• In a test I used rmp3 to decode a series of mp3s and find the maximum absolute sample amplitude of each mp3.

• First without the float feature, this is how I transformed the (int) samples into float format:

  for sample in audio.samples() {
    result_samples.push(*sample as f32 / std::i16::MAX as f32);
  }

  From my set of test files I computed these maximum amplitudes:

  [INFO] Reading track examples/kids + crimes/lorraine - kids + crimes - 02 photographs.mp3
  [src/audio_meta.rs:79] max = 1.0
  [INFO] Reading track examples/kids + crimes/lorraine - kids + crimes - 01 kids + crimes.mp3
  [src/audio_meta.rs:79] max = 1.0
  [INFO] Reading track examples/Cross Mountain/The Smallest Bones - Cross Mountain - 03 A ghost in the kitchen..mp3
  [src/audio_meta.rs:79] max = 0.9614551
  [INFO] Reading track examples/Cross Mountain/The Smallest Bones - Cross Mountain - 04 You are not (always) alone..mp3
  [src/audio_meta.rs:79] max = 1.0
  [INFO] Reading track examples/Cross Mountain/The Smallest Bones - Cross Mountain - 02 I breathe clouds..mp3
  [src/audio_meta.rs:79] max = 0.8818629
  [INFO] Reading track examples/Cross Mountain/The Smallest Bones - Cross Mountain - 01 Wear a warm coat..mp3
  [src/audio_meta.rs:79] max = 1.0
  [INFO] Reading track examples/Cross Mountain/The Smallest Bones - Cross Mountain - 05 Hands in my pockets, I walk home..mp3
  [src/audio_meta.rs:79] max = 1.0
  

• Then I enabled the float feature in the cargo manifest, and took out the format conversion:

  for sample in audio.samples() {
    result_samples.push(*sample);
  }

  Re-running my tests with the same input I now got this output:

  [INFO] Reading track examples/kids + crimes/lorraine - kids + crimes - 02 photographs.mp3
  [src/audio_meta.rs:57] max = 1.0231674
  [INFO] Reading track examples/kids + crimes/lorraine - kids + crimes - 01 kids + crimes.mp3
  [src/audio_meta.rs:57] max = 1.0081213
  [INFO] Reading track examples/Cross Mountain/The Smallest Bones - Cross Mountain - 03 A ghost in the kitchen..mp3
  [src/audio_meta.rs:57] max = 0.9614302
  [INFO] Reading track examples/Cross Mountain/The Smallest Bones - Cross Mountain - 04 You are not (always) alone..mp3
  [src/audio_meta.rs:57] max = 1.0393977
  [INFO] Reading track examples/Cross Mountain/The Smallest Bones - Cross Mountain - 02 I breathe clouds..mp3
  [src/audio_meta.rs:57] max = 0.8818281
  [INFO] Reading track examples/Cross Mountain/The Smallest Bones - Cross Mountain - 01 Wear a warm coat..mp3
  [src/audio_meta.rs:57] max = 1.0012867
  [INFO] Reading track examples/Cross Mountain/The Smallest Bones - Cross Mountain - 05 Hands in my pockets, I walk home..mp3
  [src/audio_meta.rs:57] max = 1.0026507
  

  As evident in the log, most files now produced a maximum absolute sample value that overshoots 1.0 by quite a bit, even as much as +0.039...

I know little about the technical implementation of mp3 coding so I'm a bit unsure what to make of this :) My assumption/expectation so far was that mp3 can only store sample values within a nominal audio range up to but not exceeding 0dBFS (in whichever representation, for float -1.0 - 1.0) ...

Is my assumption wrong and the mp3s in question can contain, and in fact contain, sample peak values > 0dBFS ?
Or is this possibly a bug in minimp3 and/or rmp3? (cumulative float rounding errors?)

Very curious to learn what's going on, thanks already!

Cargo features are not additive

I've just learned that Rust features are supposed to be additive, see

• rust-lang/cargo#4328
• https://dev.to/rimutaka/cargo-features-explained-with-examples-194g#dependency-of-a-dependency-beware-that-features-are-additive

The features of the rmp3 crate are not additive.

For example, if the rmp3 crate appears more than once in the dependency tree and one of the instances requests the float feature, it will be activated for all instances, most likely leading to compilation errors.

Other features like no-simd will probably not lead to compilation errors, but just to very much unexpected minimp3 build options.

I don't have any practical experience with this, is this a problem?

If yes, what is the solution?

I'm asking this because I'm working on similar bindings: https://github.com/mgeier/minimp3_ex-sys.