The LAME MP3 codec.

[kara]

This is an interesting experiment Will
So, this means that everytime Audacity is saving a wav file, the file is different 
I wonder what happens there....

k

[Oren]

This is an interesting experiment Will

My first thought in this regard is: How many other applications alter an audio file at some tiny, but fundamental, level?

Next: Are any "lossless" codecs actually completely lossless?

And finally: How many of these technical nuances are of practical concern to the recording musician?

Some of these technicalities are beginning to surface in a most comical manner, for instance: 24bit audio files are a must for those who want extended headroom and maximum dynamic range, but...a 24bit signal will not "fit" through an audio cable - the cable effectively "compresses" the signal as it passes from one component to another... so what's the friggin' point?

[folderol]

Well, I've set the cat among the pigeons over on the linux audio users list 

I've given them the URLs of the test tracks and the md5sum signatures of each of them. One guy who is, shall we say, 'interested' is the person that wrote the code Audacity uses in it's export function

I will keep you informed of developments.

BTW Oren, if my mathematics is correct, 24bit corresponds to a dynamic range of 144dB. Maybe if you helium cooled your cables you could get the noise floor down that far

Hey guys. New business model! Super-cooled audio transmission cables

Or, errrr, SCAT cables 

[Oren]

Hey guys. New business model! Super-cooled audio transmission cables
Or, errrr, SCAT cables 

SCAT.......love it!

The more techno-gibberish I hear from those who would like us to believe "more and bigger" is better, the more I'm inclined to SCOOT back to 16/44.1 audio and 128kbit MP3 and Ogg Vorbis . Some of what I hear represented in these formats is superior in every way to much of what gets the 24bit/96KHz/256Kbit treatment.

[Oren]

IMHO Lame 160 is equal to Fraunhofer Pro codec 128. 

  I still think FLAC somehow has an effect when decompressed.  Just my opinion from experimentation. 

LAME MP3 and FLAC are difficult formats to compare with traditional MP3 and lossless compression because, represented in their complete form, each has multiple levels of encoding quality. Depending on the GUI you choose to access the features of LAME and FLAC, you may be working with a relatively low-functioning version of the codec, chosen by the GUI designer because of it's encoding speed.

LAME MP3 can be encoded as CBR (constant bit rate), TBR (target bit rate), ABR (average bit rate), or VBR (variable bit rate).
CBR, TBR, and ABR are actually "crippled" versions of the codec that force it to perform more like traditional compression formats.
VBR is the version of LAME in which it performs at full capacity.
Players, although able to decode and play LAME files, cannot accurately measure the bit rate of the file, so a VBR file averaging 192Kbits/sec will show up on the player as a 320Kbit/sec file. File size, however, will be approximately the same as a CBR file encoded at 192Kbit/sec.

Currently, FLAC has 8 levels of encoding accuracy... the faster the encoding speed, the lower the accuracy. If your GUI only offers one level of encoding accuracy, it is likely one of the mid-range selections, and thus not the best FLAC can do.

Generally, open-source applications are developed by enthusiasts for enthusiasts, and a certain level of competence and familiarity is assumed. When represented by a "user-friendly" GUI, many of the features and options are rendered unavailable, for the sake of convenience. It is up to the user to find the GUI which most comprehensively represents the application, and to explore the various performance options to determine how best to configure it for a particular job.

[kara]

This tread is becoming mighty interesting 

k

[folderol]

Right then!

{rolls up sleeves}

I have some answers - not at all what I expected.

This is what Erik (the programmer of libsndfile) wrote after looking at the sample files I gave.

The differences are small, about 2 least significant bits, which suggests
that the audio has been dithered.

My guess is that Audacity has a default internal format of normalized
floats (ie range [-1.0, 1.0]) and that by default it dithers when saving
internal floating point data to a 16 bit WAV files.

In general, when converting from float to 16 bit int, dither should be
applied. However, one case where it makes sense not to dither is when
you load 16 bit integer audio data into a float internal format and then
save it back to a 16 bit integer format. In other words, the int16_t ->
float -> int16_t chain should be lossless.

If you are interested in lossless conversion from integer format to
integer format, you should try sndfile-convert which (obviously)
handles all the formats supported by libsndfile. The sndfile-convert
program by default does all conversions in 32 bit integer format
(hence int16_t -> int16_t is lossless) and only uses floating
point if either the source or destination format is float.


And this is what Fons (another respected audio programmer) wrote, after a detailed analysis of the files.

I had a closer look. As posted before the difference is
noise, numerically generated (not analog) and strangely
lowpass filtered: -3dB at around 8 Khz going down to
-20dB at Fs/2.

The noise power is -81dB FS, which is at least 14 dB
higher than would be required for any form of dithering
of 16-bit PCM. At least 2.5 bits are lost. No idea what
Audacity is trying to do, but it looks quite wrong.

Clearly now there is a problem with Audacity itself, and I have thrown it back to the list to ask where we should go from here. I don't know how serious this is in reality, or what, if any solutions there are.

However there is good news. Using sndfile-convert with its default settings from a terminal window, as Erik suggests, gives repeatable identical files, as confirmed by md5sum signatures and binary comparisons. What is more, still using default settings going wav -> flac -> wav also gives repeatable identical files.

sndfile-convert can handle a wide range of file lossless formats but not, unfortunately, the lossy ones, but I shall certainly use it in future for any wav or flac work.

As usual for Linux stuff for more info open a terminal window and type:
  sndfile-convert --help

I think the moral to be drawn here (if any) is that where you suspect 'odd' conversion behaviour, suspect the the upper layers of programming first, rather than the nuts & bolts stuff.

[Oren]

A bone-head tutorial on how to re-configure Audacity to employ sndfile-convert as it's default program would be a great boon to hosers who have not yet learned how to work with the Linux terminal. Have mercy...