Re: [LAU] Audacity strange behavior

On Tue, 11 Nov 2008 10:19:14 +1100
Erik de Castro Lopo <mle+la@email-addr-hidden-nerd.com> 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@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user