MP3 decoder ignores ENC_DELAY and ENC_PADDING

[NekoAlosama]

As an example, this file has ENC_DELAY = 576 and ENC_PADDING = 1119 according to foobar2000.
11 HYDR6C0DON$ $$$ PROD BY SIGMAR DELTA.mp3

First, Symphonia doesn't read and save the ENC_DELAY and ENC_PADDING to track.codec_params.delay and track.codec_params.padding, respectively.

Second, even if .delay and .padding has Some value, the decoder ignores these values and decodes the silence anyways, so now the decoded music is longer by ENC_DELAY + ENC_PADDING. I can't tell whether FormatOptions' .enable_gapless is or should be incorporated into whether silence is decoded or not, but changing it does nothing.

Code snippet:

// 5
// 6
let mut format_ops = FormatOptions::default();
format_ops.enable_gapless = true;

let probe_result = probe.format(
    Hint::new().with_extension("flac"),
    mss,
    &format_ops,
    &MetadataOptions::default(),
)?;
let mut format = probe_result.format;

// 7
let mut track = format
    .tracks()
    .iter()
    .find(|track| track.codec_params.codec != CODEC_TYPE_NULL)
    .expect("no supported audio tracks")
    .clone();

dbg!(track.codec_params.delay);
dbg!(track.codec_params.padding);
track.codec_params.with_delay(576);
track.codec_params.with_padding(1119);
dbg!(track.codec_params.delay);
dbg!(track.codec_params.padding);

[aschey]

It appears that file has its CRC set to 0. Running it through EyeD3 yields this

Music CRC-16        : 0000
LAME Tag CRC-16     : 0000

Symphonia enforces a valid CRC so the LAME tag info isn't being used.

[NekoAlosama]

From what I understand, CRC frames are used for error-protection when encoding from a lossless file. None of my MP3 files use CRC, mainly because I wasn't the one to encode them. I think you're implying that for each frame, CRC = 0000 instead of CRC = None or similar, but I don't know how to remove that. Maybe there should be a MetadataOption or DecoderOption or something to relax this restriction? Or maybe 0000 should be interpreted as None?

I should probably mention that I'm just using 0.5.4. The dev-0.6 branch is slightly different, but it probably works the same.

[NekoAlosama]

I have just tested the dev-0.6 branch and it doesn't seem like much functionality has changed in this area. Changing the delay, padding, or even num_frames fields do nothing on both MP3s and WAVs.

In the meantime, I'll just convert my MP3s to floating-point WAV files using foobar2000 before they get to Symphonia so the file lengths are right.

[pdeljanov]

To clarify some things, there are 3 different CRCs at play here:

1. The optional CRC contained in the MPEG frame. Symphonia ignores this since it'd break too many files to enforce.
2. The music CRC in the Info tag. The Info tag is a hacky, yet defacto, way some information is embedded into a standard MPEG frame, notably the encoder delay & padding. The music CRC is the CRC of the decoded PCM audio. Symphonia doesn't use this either.
3. The CRC of the Info tag itself. Symphonia uses this.

As noted by @aschey, the CRC of the info tag itself is 0 which is not correct. Since Symphonia is rather strict, it ignores the Info tag if the expected CRC does not match the computed CRC. Therefore the encoder delay & padding is also ignored. In this case, Symphonia is behaving as expected. If you run your app with RUST_LOG=trace, you will also see a log about this.

The ideal solution here would be to add a "strictness" option to FormatOptions and use that to control this behaviour. I'd only want to include that in 0.6. However, I'll accept a PR that special-cases 0 (have it assume there is no CRC) since 0 is the value the Info tag's CRC should be initialized with.