Hi!

I have to encode several very big wav-files which were edited in Audition 2.0 and saved in the Audition default-format "IEEE Float (0.24 float type 3) Broadcast Wave File" (file open dialog) / "32-bit Normalized Float (type 3) - Default" (file save dialog).
Now I've read in the documentation that there is an "-a"-parameter which says to be an Adobe Auditon mode for 32bit floats. So I have encoded a very large file with -hh -x6 and again with -a -l -hh -x6, but the resulting .wv-files are bitidentical.
As there's a note to NOT use this switch when compressing integer files I couldn't resist trying to encode one...^^ And: the results with or without this switch are the same!

So can anybody tell me what this switch is really good for, and if I should use it for my Audition-files? Or is wavpack (4.40, 4.41 used) ignoring this switch as even with 16bit-files there is no difference?

Thank you!

Bryant, perhaps you do know the answer?

By the way, today I encoded two ~7GB-Audition-Files in parallel (Dual-Xeon, 2x3,6GHz, 800FSB, 2MB L2 Cache) using the 4.41beta; while it took me about 10h to encode a 3,6GB-file yesterday (while I was working with the system, though) I let my system run the whole day while I was at work and when I got home the files were already finished encoding! That means that files with approx. double the size encoded in less time than the "small" one yesterday!

So 4.41 shows an improvement of ~50% (!!) on my system when using the highest possible setting; of course this is no CD-music, but a 32bit-float, but: hey! Impressive!

The -a switch does still work in WavPack, but it generally won't make any difference.

The problem it addresses only happens when you save IEEE float files in Audition (or Cooledit) as "type 1" integer files (either 16.8 or 24.0). This means that the WAV header that Audition writes indicates that the file is an integer file, but it really contains float data normalized to a different range than Microsoft decided would be the WAV standard. The switch can only make a difference when the file matches one of these two special situations where we would not otherwise know if the file was integer or float.

BTW, when I was working on this I wondered how Audition knew which it was and discovered that it actually looks through the first few seconds of audio and guesses which it is (and this works okay, but because zero is the same represented as float or integer, you can fool it by having several seconds of pure silence at the beginning of your file).

Anyway, as long as you save as "type 3" IEEE float (like you're doing) you won't run into any problem (and the switch will do nothing).

BTW, I'm glad that 4.41 is showing up faster for you (although I have to say your test didn't sound too scientific!)

David

Hi Bryant,

thank you for your answer!
I'm glad that I don't have to try this switch from now on on my Audition-files, as my habbit of encoding only with the most advanced mode would have made this effort a very long lasting one...

You're right, it's really not a scientific test, and it wasn't intended to be one. I just noticed.
Btw., does the type of audio (genre) make any difference in encoding speed, or is it purely "Seconds/Megabyte"?
Perhaps I can try encoding identical files again on weekend and tell you my results.

What I noticed, too, is that the compression ratio of the large files I encoded yesterday is much worse (~38%) than of the small file the day before (~45%), although the audio from the small file is part of the larger ones; both are recordings from Robbie Williams' live cast in Vienna.
The small file is purely the concert, whereas the larger files contain an hour before and after the concert, too; there were interviews with him and the station played several of his songs. It's a very popular radio station in Austria, but also with a very overdone dynamics compression. Do you think that this compression might occur particularly before and after the concert and hurt compression ratio that much?
Is there a possibility to analyse the wv-files not just for average compression ratio but for actual bitrate?

Thanks!

There is something unintuitive about lossless encoding of floating-point audio. If the floating audio samples are exact representations of, say, 24-bit integer samples, then the compressed size of the float audio will be almost exactly the same as the compressed size of the original 24-bit integer samples. However, if any processing has been done on the data since it was captured from the ADC (even simple gain adjustment) then it might take considerably more space compressed because many of the samples will get non-zero bits with less significance than what a 24-bit integer can hold (in other words, they become 24-bit integers plus fractions). I believe that the overall effect can mean well over 10% worse compression.

You can get an idea if this is affecting your compression ratio by trying the -p switch in WavPack. What this does is force each block to be stored as essentially normalized 25-bit integers, with all fractional bits thrown away. If this improves your compression ratio, then some processing has been done on the samples since they were captured and you are (to some extent) wasting space. I would go ahead and use the -p option for material like this anyway because there's no way that there's useful information below 25-bits from something that started as a 24-bit (or 16-bit!) capture.

Ignoring that issue, the single most important factor for determining the effectiveness of lossless compression is average level. My guess would be that the live material would have more "dead time" between songs and probably would be less dynamically compressed than CD tracks (otherwise it wouldn't sound "live"), but this is just a guess. You can always bring it back into Audition and do level analyze if you're really curious.

As for the encoding speeds, WavPack will generally run at about the same rate regardless of the material. However, the higher -x modes (4-6) can vary in speed somewhat more because some of their procedures continue to loop until they can't improve the compression any more, which could happen quickly or take much longer. I haven't had the patience to test any of that however...