Re: [LAU] Audacity strange behavior

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

-- 
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"UNIX was not designed to stop you from doing stupid things,  because
that would also stop you from doing clever things."  -- Doug Gwyn
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user