On Tue, Jul 31, 2007 at 10:25:34PM +0200, Marc-Olivier Barre wrote: Nope. That'd be nice but as I said earlier, FLAC can't handle Ardour's wav files: pw@kermit sounds $ flac Audio\ 1-1.wav flac 1.1.2, Copyright (C) 2000,2001,2002,2003,2004,2005 Josh Coalson flac comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. Type `flac' for details. options: -P 4096 -b 4608 -m -l 8 -q 0 -r 3,3 Audio 1-1.wav: ERROR: unsupported compression type 3 But as pointed out earlier in the thread, wavpack is open source and it seems to work. -- Paul Winkler http://www.slinkp.com

Paul Winkler wrote: I only meant natively reading them. On 8/1/07, Stefan Kost <ensonic(a)hora-obscura.de> wrote: Well if FLAC can be read by ardour directly, gstreamer is not such a bother... I can include that in my script. Paul Winkler wrote: I'll give a try to wavpack too and tell you how things went. _________________ Marc-Olivier Barre.

I got 32-bit true lossless j2kaudio transcoding working today. I compared it against wavpack and wavpack seems far superior in terms of speed and compression for 32-bit floating point data. I created the test files with audacity, which only uses float values from +1 to -1, so I am not sure if it actually uses the full 32-bits, but it is still good enough for a meaningful test. Here are the compressed size % for the worst case that I tested: 32bWN.wav 44.1kHz/32b/10ch 60sec 10 channels of white noise 105840152B j2kaudio 91.06 wavpack 82.32 tar czf (gzip) 92.29 tar cjf (bz2) 93.24 The full test tables are here: http://geocities.com/hildstrom/projects/j2kaudio/ Are there any wav/audio programs out there that use the full float range of 3.4e+/-38? It seems to me that this larger range would use more of the 32 bits. Thanks. -Greg --- Marc-Olivier Barre <mobarre(a)gmail.com> wrote:

On Wed, Aug 01, 2007 at 10:45:59AM -0700, Gregory Alan Hildstrom wrote: That's not how float works. *Any* floating point number uses the full precision of all 32 bits (or 64, or whatever). This is because the radix point (like decimal point, but binary) can be anywhere. What you're saying would be true of fixed-point numbers. http://en.wikipedia.org/wiki/Floating_point -- Paul Winkler http://www.slinkp.com

Yes, I understand that any single 32-bit floating point number occupies 32 bits. I am specifically talking about sets of numbers and the number of bits actually used to represent the set. My basic thought is summarized in this example: If you limit your range of possible values to positive numbers, the sign bit is useless to you because it is always 0. This is true because of how you are using the variable; not because of the variable's implementation. The sign bit will still be stored in the float variable, but it is wasted space and precision if you do not use it. Your data could be represented with 31 bits instead of 32. Obviously wav data is signed, but this illustrates my point. I saved a 32-bit 44.1kHz 2-channel wav file using Audacity. The left channel was a full-amplitude sine wave sweep from 20Hz to 20kHz. The right channel was a full-amplitude square wave sweep from 20kHz to 20Hz. The exponent portion of a float variable is 8 bits, which can represent 0-255 if treated as an unsigned integer. I added a line of code to j2kaudio to print out the exponents of each float sample while reading the wav file, which I redirected to a file and plotted with gnuplot. The exponents ranged from 106 to 127, which is a range of 21. The 21 exponent values can be represented with 5 bits (2^5=32). I would argue that my wav file, saved with Audacity and ranging from -1 to +1 could be saved with a 5-bit exponent instead of an 8-bit exponent. Each 32-bit float value occupies 32 bits, but at most only 32-8+5=29 bits needed to be flipped in my wav file; I did not examine the mantissa. I then tried to create another 32-bit wav file with a greater dynamic range. I created a 1Hz sine wave at full amplitude. I then used the amplify tool (-50dB) to reduce its peak amplitude to -600dB, which is an incredibly tiny signal. I then added a second channel with a full amplitude sine wav. The small signal would be totally inaudible next to the normal signal. The exponent range was 0-10 for the incredibly small sine wave values near 0. The exponent range was 106-128 for the full amplitude sine wave. The total range I was able to create with Audacity was 0-127, still 1-bit shy of an 8-bit exponent, but those additional exponent values I manufactured were only used to define incredibly tiny numbers near the zero crossing. I guess I do not understand why I would use such a high-dynamic-range variable (32-bit float) and artificially limit its range to +/-1 (31 bits). I also do not understand why such a high-dynamic-range variable is necessary for audio reproduction given the limits of human hearing. I do understand why you might want to use it for various computations. I do not know if this is an Audacity-specific limitation or standard industry practice. These are just a couple of my hangups that I did not do a very good job of explaining before. Please clue me in if I am missing something. Thanks. -Greg --- Paul Winkler <pw_lists(a)slinkp.com> wrote:

Well, you guys have clearly dug into this a lot deeper than I have, so I withdraw my ignorant statements :) -PW -- Paul Winkler http://www.slinkp.com

So does Ardour allow 32-bit float values to exceed +/-1.0? Audacity does not seem to allow this. -Greg --- Paul Davis <paul(a)linuxaudiosystems.com> wrote:

The reason for using floats is as you said, it's huge dynamic range does far exceed human hearing or any reproduction hardware, but it is handy for internal computations. Floats are practically impossible to clip, and even very quiet signals get at least 24 significant bits. Many filters and effects can have internal stages at a level very different than the signal. The reason ardour uses floats is because it's what jackd uses, so it's the most straightforward way to record losslessly. Jackd uses it because it assumes there may be several processing stages between the input and output. For example, a given channel may be recorded from a microphone, go through a compressor, some reverb, a gain stage, then be mixed with several other channels. It makes more sense to perform the integer -> float conversion once at the A->D, and once again at the D->A, than to perform it between each linked stage. The conversion is not necessarily lossless, so each conversion has some cost in noise and distortion. Jack isn't the only software using floats; I know at least Apple's Core Audio uses floats end-to-end too. LADSPA plugins use floats on inputs and outputs by specification, which I think predates jack. I imagine floats are used internally for a good many effects that have integer inputs and outputs, and I seem to recall some DAW softwares touting their (sometimes double precision) floatiness as a feature. On Wed, Aug 01, 2007 at 02:18:14PM -0700, Gregory Alan Hildstrom wrote: