4

I understand that MP3 is not recommended for production as it is lossy, but that is irrelevant here.

I understand that the MP3 encoding algorithm inserts silence in the first second to pad out the block amongst other reasons. However, upon further inspection, the algorithm also inserts random nonsense values amongst the silence. Puzzled, I tried it out on a plain beat (VES2 Bassdrum 001) as shown below.

Exhibit A: 'VES2 Bassdrum 001' WAV

I then proceeded to export as MP3 at the highest quality possible with the LAME plugin:

Exhibit B: Exporting

Afterwards, I opened the exported file, and lo and behold, there was random "static" values before the kick! To be exact, 2257 samples worth of nonsense. That's ~0.0512 seconds worth of randomness:

Exhibit C: 'VES2 Bassdrum 001' MP3

If you also look closely, you can see the encoder chopped off some values at the end of the sample!

What I'm wondering is why does the algorithm decide to put the random values at the front of the first chunk instead of the end of the last chunk? I'm also wondering, why are the random values random? Why can't the encoder just use 0.0?

Cole Tobin
  • 679
  • 1
  • 6
  • 13
  • 3
    I am a novice, but my guess is that this is look-ahead behavior. If I recall correctly, encoders can have quality issues with percussive sounds, and the method used to defeat this is called "block switching" and "pre-echo reduction" The noise itself is probably some form of quantization of the silence with the signal. the audio equivalent of the noise halos at high-contrast edges in a jpeg. –  Jun 19 '13 at 18:31
  • After further reaserch, a LAME3.99 encoded file will decode with 2257 unwanted samples in LAME3.99, but only 1105 in FFmpeg. An FFmpeg 0.6.2 encoded file will decode with the same amount of unwanted samples in both, but as far as I can tell, a random amount. – Cole Tobin Jul 28 '13 at 23:31
  • Can you zoom into the "noise", also vertically? My guess is that this is some form of build up to the "kick" sound, because of spatial resolution loss during compression. – Marcel Apr 20 '22 at 06:28

1 Answers1

4

What I'm wondering is why does the algorithm decide to put the random values at the front of the first chunk instead of the end of the last chunk? I'm also wondering, why are the random values random? Why can't the encoder just use 0.0?

The noise is almost certainly coming from the decoder not the encoder. The encoder processes the audio and produces a set of coefficients that represent the audio content. This is frequency-domain data, not the time domain data that you see when you open up the audio file in an editor like Audacity. When you open your MP3 file up, Audacity has to translate the MP3 data into audio data. So you aren't looking at what is stored in the MP3 file, you are looking at the result of transforming that data via your MP3 decoder into audio data.

Most likely, the encoder isn't even recording 0.0 for the data. It stores the coefficients that represent the compressed data, and then probably also stores time offsets that allow the audio block to be properly positioned once it has been decoded.

ObscureRobot
  • 4,380
  • 11
  • 20
  • 1
    Sure, but the encoder isn't padding the file with noise - that would just make the file larger. The decoder is using the stored coefficients to try to reconstruct audio and ends up inserting noise. – ObscureRobot Jun 21 '13 at 14:37
  • 1
    Check the documentation for your decoder, if any. – ObscureRobot Jun 22 '13 at 03:37