The JasPer library documentation states that a single image component can be from 1 to 16 bits per sample, so not directly. 24-bit color images are actually treated as 3 8-bit components: like one red component, one green component, and one blue component. For lossless compression, we could easily place the most significant 16 bits in the first image component and place the least significant 16 bits in a second image component of each frame. It should also be possible to code something up that does the same sort of 16-bit splitting into 2 flac files. -Greg --- Paul Winkler <pw_lists(a)slinkp.com> wrote: _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev(a)lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev

Can wav files store 32b float?

Why is it ironic to see those statements right next to each other? ;)

(Not looking to open a can of worms; I know they are not equivalent due to the relatively constant limitations on the human ear's perception of dynamic range. Just saying ... :)

-Forest -- Forest Bond http://www.alittletooquiet.net

Pretty cool. Does JPEG 2000 handle float data? I'd love to be able to write an archive script for Ardour sessions that compresses the audio data losslessly, but FLAC won't do it.

Or Matroska. Ogg and Matroska are not (yet?) supported by libsndfile, though.

I certainly appreciate everyone's comments. I have 16-bit, 8-bit, mono, and stereo tested at many differrent sample rates so far, but it should be able to handle any number of channels < 65536. I will work to make it flexible enough to handle 24-bit, 32-bit, and 64-bit, but no promises. =;) I have no plans to learn how to use any sort of container format yet because I want to concentrate on compression and data types. Any container with frames can be used quite easily; just shove audio data encoded as JPEG 2000 JP2 images in a container using my methods; the compression and framing do not change. I will continue with the KISS approach and just modify my extremely simple j2a format for now. I will add some fields like sample rate, number of channels, number of frames, and precision to the header, so it can be read without decoding a frame. I will also put an arbitrary header before the first audio frame to contain anything a developer/user wants. This arbitrary header could be an id3 tag, photo, md5sum, j2a file...anything. fps sample rate number of channels number of frames precision arbitrary header size arbitrary header data frame size frame JP2 data frame size frame JP2 data ... EOF Someone pointed me to some great links and suggested that I test against additional lossless codecs, but I can only do that to a point because I must focus my efforts. The large CD-quality test data set compression numbers make me to want to test against the top 3 average compression ratio codecs: LA, OptimFROG, and Monkey's Audio. I will need to broaden my search once I start heavily testing 32-bit, but I am not there yet. I would be happy to integrate j2kaudio into another library or program once I feel it is mature enough. Thanks again for all of the helpful feedback. -Greg --- Erik de Castro Lopo &lt;mle+la(a)mega-nerd.com&gt; wrote: _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev(a)lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev

Currently I store my albums into one flac file per CD plus separate CUE sheet. It's far from perfect. I would like to have just one file per album with all the content inside (eg. audio, pictures, lyrics, videoclips, bonuses, etc...) and player with direct acces to all that content. It would be great for archiving and distributing records over internet.

Hello again. I discovered a disappointing, to me, bug in j2kaudio/libjasper today while I was working on 32-bit audio support. My previous holy-grail-looking lossless audio compression test results were incorrect. I was passing rate=1 to the JasPer JPEG 2000 encoder, which was not performing lossless compression, but slightly lossy compression. I actually do not know what it was doing because the behavior I was getting is somewhat undocumented. I could not differentiate the quality by ear; everything sounded perfect to me. I only discovered this when I had to do sample by sample checks for accuracy and I found that they were very close, but not exactly the same. The results matched exactly when I left rate= out of the encoder options entirely, but the resulting file size increased. I will post a question to the jasper email list to find out what rate=1 should be doing and why it does not match omitting the rate. The new lossless results from my test song are: la - 65.5% ofr - 66.3% ma - 66.9% lpac - 69% flac - 70.2% shorten - 75.2% j2kaudio - 76.6% (dead last) bzip2 - 96.7% gzip - 97.1% Thank you again for all of your feedback and input. I apologize for getting anyone's hopes up and for not performing a sample-by-sample check at the integer level sooner. For now, I think I have proved and improved the concept, but I conclude that even though it outperforms file compressors, other lossless and lossy audio compressors are superior for audio data. Updated tables and information: http://geocities.com/hildstrom/projects/j2kaudio Thanks. -Greg Gregory Alan Hildstrom Secure Systems Engineer - Trusted Computer Solutions trustedcs.com ghildstrom(a)trustedcs.com Software Engineer - Hildstrom Engineering geocities.com/hildstrom hildstrom(a)yahoo.com Mobile:(210)413-6082 Fax:(210)599-0469 Office:(210)340-3151x117 _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev(a)lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev