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 <[EMAIL PROTECTED]> wrote: > Thorsten Wilms wrote: > > > > - Have you thought of putting your codec data inside other standard > > > container formats like WAV, Caf and Ogg? > > > > Or Matroska. Ogg and Matroska are not (yet?) supported by libsndfile, > > though. > > Unfortunately, Ogg seems to be a surprisingly difficult. To fit > easily into the libsndfile view of the world libsndfile needs > to be able to find out how many frames of audio are in the file, > preferably without doing too much seeking about. > > So far I have only tried to do OggFlac and haven't managed to get > very far. I don't know if this is something specific to OggFlac or > more generally a property of Ogg. However, I do know that two > people have tried to add OggVorbis to libsndfile without being able > to complete the task. > > Erik > -- > ----------------------------------------------------------------- > Erik de Castro Lopo > ----------------------------------------------------------------- > "Imagine if every Thursday your shoes exploded if you tied them > the usual way. This happens to us all the time with computers, > and nobody thinks of complaining." -- Jef Raskin > _______________________________________________ > Linux-audio-dev mailing list > [email protected] > http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev > _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev
