On Tue, 11 Nov 2008 10:19:14 +1100 Erik de Castro Lopo <mle+la@xxxxxxxxxxxxx> wrote: > Folderol wrote: > > > OK, there are four files: > > > > http://www.musically.me.uk/music/Test1.wav > > http://www.musically.me.uk/music/Test2.wav > > http://www.musically.me.uk/music/Test3.wav > > http://www.musically.me.uk/music/Test4.wav > > > > Test1 is a short excerpt from the original recording that I > > investigated. It is well clear of any clipping margins etc. > > > > Test2-4 are copies made with Audacity's export function, and were made > > one after the other, within seconds of each other, and without touching > > anything else in Audacity (or any other application for that matter). > > > > All have exactly the same byte count, and look identical to me in > > Audacity. > > Visual inspection is not really up the the task :-). > > I've got a little curses hexdump utility that I use for this kind of > comparison: > > http://www.mega-nerd.com/erikd/Blog/Tools/hv.html > > which shows something like this for "hv Test[234].wav": > > 00000000: 52 49 46 46 A8 02 49 00 57 41 56 45 66 6D 74 20 RIFF..I. WAVEfmt > 52 49 46 46 A8 02 49 00 57 41 56 45 66 6D 74 20 RIFF..I. WAVEfmt > 52 49 46 46 A8 02 49 00 57 41 56 45 66 6D 74 20 RIFF..I. WAVEfmt > > 00000010: 10 00 00 00 01 00 02 00 44 AC 00 00 10 B1 02 00 ........ D....... > 10 00 00 00 01 00 02 00 44 AC 00 00 10 B1 02 00 ........ D....... > 10 00 00 00 01 00 02 00 44 AC 00 00 10 B1 02 00 ........ D....... > > 00000020: 04 00 10 00 64 61 74 61 84 02 49 00 00 00 02 00 ....data ..I..... > 04 00 10 00 64 61 74 61 84 02 49 00 FE FF 02 00 ....data ..I..... > 04 00 10 00 64 61 74 61 84 02 49 00 01 00 FF FF ....data ..I..... > > 00000030: FC FF 05 00 FB FF 02 00 01 00 FE FF 02 00 FE FF ........ ........ > FD FF 03 00 FD FF 01 00 02 00 FC FF 05 00 FA FF ........ ........ > 00 00 00 00 00 00 FF FF 02 00 FE FF 02 00 FD FF ........ ........ > > 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. > > HTH, > Erik Thank you very much for going into this in such detail and so quickly. I can confirm that using sndfile-convert directly gives completely identical files. This is true when going wav -> wav and also wav -> flac -> wav -- Will J Godfrey http://www.musically.me.uk _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
