Extreme audio encoding

Have you ever wondered how the existing compression formats will behave with losses in completely abnormal conditions? Usually they successfully mask the deleted information, and the ear of an inexperienced user does not hear the difference. Or maybe it is the lack of acoustics today, and after it is updated, tomorrow everything will pop up?

On the Internet you can find a lot of information about blind testing of various formats and comparing spectrograms. It has long been made a lot of conclusions about what quality is preferable. But the main recommendation remains one - rely on your ears. And here it may turn out that someone and MP3 128kbps will fall for the CD-quality - most likely, there is still a lot of good acoustics to buy, and maybe a bear has come to ear. How to be?

I propose to conduct a completely abnormal, but nonetheless visual experiment. To hear the difference, we will encode the sound not one, but 5, 10 or 50 times!

With each re-coding, the encoder will delete all new and new information that, in his opinion, the human ear will not hear. Our task is to identify the minimum bitrate of the popular lossy compression formats (MP3 and Ogg Vorbis), which, with 100 iterations of transcoding, will keep the sound almost indistinguishable from the original.
')

Training

For MP3 encoding, we will use the latest stable version of LAME (3.98.4) . To automate the process of re-encoding will make a small bat file. The scheme of work is simple: we encode the wav file into mp3, then we decode it back into wav, then we encode the already received wav, etc.

@ copy /Y %1 ~temp.wav
@ for /L %%i in (1,1, %3 ) do @(
@ echo -------------------------------------------------------------------------------
@ echo -- Iteration %%i
@ echo -------------------------------------------------------------------------------
lame %4 ~temp.wav ~temp.mp3
lame --decode ~temp.mp3 ~temp.wav
)
@ copy /Y ~temp.mp3 %2
@ del ~temp.wav
@ del ~temp.mp3

Let's call it mp3_xcode.bat. The startup format looks like this:

mp3_xcode <input.wav> <output.mp3> <iterations> "<lame params>"

For Ogg Vorbis, we use OggEnc aoTuV b5.7 . Make a bat file for this format.

@ copy /Y %1 ~temp.wav
@ for /L %%i in (1,1, %3 ) do @(
@ echo -------------------------------------------------------------------------------
@ echo -- Iteration %%i
@ echo -------------------------------------------------------------------------------
oggenc %4 -o ~temp.ogg ~temp.wav
oggdec -w ~temp.wav ~temp.ogg
)
@ copy /Y ~temp.ogg %2
@ del ~temp.wav
@ del ~temp.ogg

Let's call it ogg_xcode.bat. The startup format looks like this:

ogg_xcode <input.wav> <output.ogg> <iterations> "<oggenc params>"

If you want to experiment on your own, the sndexp.7z archive (1.3 MB), which includes all the necessary files, is useful to you.

Reade set Go!

Below you will see many links to audio files. I recommend using a player that can play files directly via an http link (for example, foobar2000 ).
The original composition in all cases was a rich passage from the composition “O Fortuna” performed by Therion. Download it here: fortuna.flac (2.8Mb) or fortuna.ogg (466Kb).
So let's get started.

The first frontier: ~ 128kbps

We will encode in VBR, therefore we will select the parameters that produce an average of 128kbps.

mp3_xcode fortuna.wav fortuna_128x10.mp3 10 "-V 6"
ogg_xcode fortuna.wav fortuna_128x10.ogg 10 "-q4"

Get the files:

x10	fortuna_128x10.mp3 (340kb)	fortuna_128x10.ogg (360kb)
x50	fortuna_128x50.mp3 (326Kb)	fortuna_128x50.ogg (367Kb)

These examples clearly show that MP3 and Ogg Vorbis have a completely different coding approach. After each re-encoding, the sound in the MP3 becomes more and more like white noise. In Ogg Vorbis, the effect is completely different - the sound becomes more dull.
In all cases, we got a disgusting result.

Raise the bar: ~ 192kbps

We select the parameters that give approximately 192kbps.

mp3_xcode fortuna.wav fortuna_192x10.mp3 10 "-V 2"
ogg_xcode fortuna.wav fortuna_192x10.ogg 10 "-q6"

Get the files:

x10	fortuna_192x10.mp3 (533kb)	fortuna_192x10.ogg (528Kb)
x50	fortuna_192x50.mp3 (531Kb)	fortuna_192x50.ogg (552Kb)

In this test, with 10 transcoding, Ogg Vorbis performed significantly better than MP3. You can already force yourself to listen to it, but you can clearly feel a huge amount of artifacts. At 50 it is already impossible to listen. Verdict - test failed.

Higher: ~ 256kbps

We select parameters that give approximately 256kbps.

mp3_xcode fortuna.wav fortuna_256x10.mp3 10 "-V 0"
ogg_xcode fortuna.wav fortuna_256x10.ogg 10 "-q7,3"

Get the files:

x10	fortuna_256x10.mp3 (624Kb)	fortuna_256x10.ogg (624Kb)
x50	fortuna_256x50.mp3 (624Kb)	fortuna_256x50.ogg (747Kb)
x99	fortuna_256x99.mp3 (624Kb)	fortuna_256x99.ogg (849Kb)

Here, with 10 coding iterations, both formats gave approximately the same result. However, already at 50, the old man MP3 is already beginning to significantly win against Ogg Vorbis. And the latter as a result has a higher bitrate! In order to check the trend, the number of iterations was increased to 99. The trend has continued: the MP3 is still relatively listenable, and Ogg Vorbis is significantly inferior in this.

And finally: ~ 320kbps

Since the -V parameter cannot be set below 0, we will use the -b 320 parameter. For OggEnc, we will do the same. At the same time, Ogg Vorbis will work in VBR mode, and MP3 in CBR mode.

mp3_xcode fortuna.wav fortuna_320x10.mp3 10 "-b 320"
ogg_xcode fortuna.wav fortuna_320x10.ogg 10 "-b 320"

Get the files:

x10	fortuna_320x10.mp3 (862Kb)	fortuna_320x10.ogg (888Kb)
x50	fortuna_320x50.mp3 (862Kb)	fortuna_320x50.ogg (1099Kb)

After 10 iterations of coding, both formats had a good result. You can listen to it, and MP3 is difficult to distinguish from the original. With 50 iterations, unpleasant artifacts are clearly audible in both formats, and Ogg Vorbis plays MP3s a little, not looking at the fact that with each re-encoding it automatically increased the bitrate.

Verdict

• Ogg Vorbis is better than MP3 at bit rates up to 256kbps
• MP3 is better than Ogg Vorbis at bit rates from 256kbps to 320kbps
• Ogg Vorbis coder hardly digests previously coded data, therefore it increases bitrate
• The tested encoders of both formats with repeated transcoding could not provide transparent sound on all tested bitrates

findings

In the light of some absurdity of the whole experiment, please do not take the writing too seriously. All this can be just one of the reasons to think about the storage of the home music collection of lossless formats like FLAC . Perhaps this is the only reasonable conclusion that could be drawn from the written.

PS Candidate for the title of pseudo-lossless

In 2002, the OggEnc GT3 coder (176Kb) was popular for encoding Ogg Vorbis. When coding at maximum quality, it gives an average bitrate of more than 500kbps. A little later, I tried to use it for our experiment, and as a result I was surprised: even after a thousand recodings, it seems I cannot distinguish the resulting file fortuna_q10x1000.ogg (1421Kb) from the original. Yes, and the average bitrate of the resulting file almost did not change after each iteration. The latest official version of the Ogg Vorbis coder and the popular version of aoTuV, even with 100 recodings, gave a bad result. So the old GT3 with the best quality codes best. However, GT3 did not perform as well on other bitrates.