4 Mar
2007
4 Mar
'07
4:58 p.m.
Hi!
I'm interested in losless compression of typical Jack audifiles
for exchange. That means float32 sample format.
Flac doesn't handle float, only pcm.
wavpack handles both.
So I was told that converting from (wav) float32 to pcm24 and back
should be losless, if the float file is normalized. This would cut
down on file-size by itself and allow to use Flac.
I tested this using sndfile-convert and diff tells me there are
differences. The file sizes are identical.
diff did not report differences for a wav-unpacked file (staying
in float32).
Now I wonder if I did something wrong (I'm pretty sure the source
file is normalised), or if there's a bug in sndfile-convert or
if the differences are in the header. diff is a tool for text,
after all.
Anyways, file size results, didn't care about time:
48kHz, float 32:
- original wav: 59.1 MB (my Aliethno track)
- wavpack: 39.9 MB
pcm24:
- wav: 44.4 MB
- wavpack: 32.3 MB
- flac: 37.4 MB
I used wavpack -h and flac -8 for best compression ratios.
(Well, just saw wavpack has a -hh switch)
--
Thorsten Wilms
Thorwil's Creature Illustrations:
http://www.printfection.com/thorwil
4 Mar
4 Mar
5:38 p.m.
New subject: [linux-audio-user] Flac vs wavpack and float32 to pcm24 conversion tests
Thorsten Wilms wrote:
Hi!
I'm interested in losless compression of typical Jack audifiles
for exchange. That means float32 sample format.
Hmm, interesting.
Flac doesn't handle float, only pcm.
wavpack handles both.
So I was told that converting from (wav) float32 to pcm24 and back
should be losless, if the float file is normalized.
I would be **very** surprised if it was. For a normalised WAV file
the maximum value would be 1.0 which will correspond to a pcm24
value of 0x7ffffff. The float32 file could also contain a sample
with a value of 1/(2^25) which is smaller than the pcm24 value of
0x1. Hence, float32 -> pcm24 -> float32 is not lossless.
This would cut
down on file-size by itself and allow to use Flac.
I tested this using sndfile-convert and diff tells me there are
differences. The file sizes are identical.
diff did not report differences for a wav-unpacked file (staying
in float32).
The wavpack algorithm must do soemthing special with float32 data.
Maybe what you want to do is add wavpack to libsndfile :-).
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo
+-----------------------------------------------------------+
"If POSIX threads are a good thing, perhaps I don't want to know what
they're better than." -- Rob Pike
6:22 p.m.
New subject: [linux-audio-user] Flac vs wavpack and float32 to pcm24 conversion tests
On 3/5/07, Erik de Castro Lopo <mle+la(a)mega-nerd.com> wrote:
Maybe what you want to do is add wavpack to libsndfile
:-).
Great idea, Erik!
We are waiting :)
Kind regards,
Happy libsndfile users.
8:53 p.m.
New subject: [linux-audio-user] Flac vs wavpack and float32 to pcm24 conversion tests
Dmitry Baikov wrote:
On 3/5/07, Erik de Castro Lopo
<mle+la(a)mega-nerd.com> wrote:
I'm ***rather*** busy. Are you volunteering? :-).
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo
+-----------------------------------------------------------+
Microsoft is finally bringing all of its Windows operating system families
under one roof. It will combine all of the features of CE, stability and
support of ME and the speed of NT.
It will be called Windows CEMENT...
Maybe what you want to do is add wavpack to
libsndfile :-).
Great idea, Erik!
We are waiting :) 
7:33 p.m.
New subject: [linux-audio-user] Flac vs wavpack and float32 to pcm24 conversion tests
On Mon, 2007-03-05 at 08:37 +1100, Erik de Castro Lopo wrote:
I would be **very** surprised if it was. For a
normalised WAV file
the maximum value would be 1.0 which will correspond to a pcm24
value of 0x7ffffff.
i see no problem with that value, assuming you mean it represent 2^24-1.
do you?
The float32 file could also contain a sample
with a value of 1/(2^25) which is smaller than the pcm24 value of
0x1. Hence, float32 -> pcm24 -> float32 is not lossless.
IEEE 32 bit floating point has 1 sign bit and 23 bits of mantissa. i
don't see how you can get 1/(2^25) out of that. the small representable
value with an effective non-unity exponent (i.e. ignoring the bias
stuff) is 1/(2^23), isn't it?
awaiting enlightenment ....
8:53 p.m.
New subject: [linux-audio-user] Flac vs wavpack and float32 to pcm24 conversion tests
Paul Davis wrote:
On Mon, 2007-03-05 at 08:37 +1100, Erik de Castro Lopo
wrote:
No, 2^23 -1. We need a sign bit. Remember? :-)
In signed 24 bit numbers all negative numbers have the most significant
bit set and all negative numbers have it clear. That means the maximum
positive 24 bit number is 0x7fffff.
I would be **very** surprised if it was. For a
normalised WAV file
the maximum value would be 1.0 which will correspond to a pcm24
value of 0x7ffffff.
i see no problem with that value, assuming you mean it represent 2^24-1.
do you? IEEE 32 bit floating point has 1 sign bit and 23 bits
of mantissa. i
don't see how you can get 1/(2^25) out of that. the small representable
value with an effective non-unity exponent (i.e. ignoring the bias
stuff) is 1/(2^23), isn't it?
That value (1/(2^25)) was just given as an example.
Let me put it another way. The smallest value we can respresent with
signed 24 bit numbers as a notmalised float is
1.0 / 0x7fffff
But, the value
1.0 / (0x7fffff + 1.0)
is also a legal normalised float value but it is less than the smallest
value that can be represented as signed pcm24.
This is basically an existance proof that there are normalised floating
point numbers that will not survive the
float32 -> pcm24 -> float 32
transformation.
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo
+-----------------------------------------------------------+
Linux, the UNIX defragmentation tool.
9:56 p.m.
New subject: [linux-audio-user] Flac vs wavpack and float32 to pcm24 conversion tests
On Mon, 2007-03-05 at 11:53 +1100, Erik de Castro Lopo wrote:
This is basically an existance proof that there are normalised floating
point numbers that will not survive the
float32 -> pcm24 -> float 32
transformation.
i stand humbly corrected. i guess i confused the fidelity of pcm24 ->
float32 -> pcm24 with its "inverse". thanks for the clarification.
--p
6548
days inactive
6548
days old
linux-audio-user@lists.linuxaudio.org
6 comments
4 participants
participants (4)
-
Dmitry Baikov -
Erik de Castro Lopo -
Paul Davis -
Thorsten Wilms