Hi folks, I'm doing a merge of my current branch onto the mainline (for testing) today. I believe it to be stable. Just a little more vorbisfile testing. After the merge, I have a few more patches to apply, then onto cascading/coupling. New stuff: Floor backend 1 and residue backend 1; both are present, but the mainline modes won't use either yet. Naturally, both are enabled for decoding future streams that use them. Floor 1 is a piecewise linear approximation of the spectral envelope. Advantages: more stable local spectral behavior (no more spreading stereo image at lower bitrates), more control over tuning specific error characteristics. Disadvantages: it takes more bits than LSP, but not by an absurd margin (20%-30% premiun). Residue 1: Same as residue 0, but uninterleaved. The advantages are that this is faster and allows one to more easily exploit adjacent-line structure in the MDCT, assuming that that's what the codebook model wants to do. Vorbisfile optimizations; I took HB's optimization patch, fixed a few infinite loop problems in it, and then decided to go a little nuts eliminating unneeded machine initializations and decoding work. The end result is that ov_open (and friends), ov_raw_seek and ov_pcm_seek_page are more than 100x faster (and even faster than that on a network file system), and the other seek functions (that do actually require some internal background PCM decode to get sample boundaries right) are a shade under 2x faster (again, much larger margin on distributed file systems). I also added an ov_test() function as a fast partial open that verifies the vorbis-ness of a file (and loads the headers for perusal), but doesn't seek to learn the chain structure or total length. A partially open file can then be fully opened using ov_test_open(). Libvorbis now has an official vorbis_packet_blocksize() function to learn the block size of a packet without decoding it. Libogg also has one new function, ogg_stream_packetpeek(), which fetches the next packet in a logical stream without removing it from the stream head. None of these changes should affect binary compatability with prebuilt applications. Monty --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Monty wrote:> > Hi folks, > > I'm doing a merge of my current branch onto the mainline (for testing) > today. I believe it to be stable. Just a little more vorbisfile*applaud*> testing. After the merge, I have a few more patches to apply, then > onto cascading/coupling.hurray!> New stuff: > > Floor backend 1 and residue backend 1; both are present, but the > mainline modes won't use either yet. Naturally, both are enabled for > decoding future streams that use them. > > Floor 1 is a piecewise linear approximation of the spectral envelope. > Advantages: more stable local spectral behavior (no more spreading > stereo image at lower bitrates), more control over tuning specific > error characteristics. Disadvantages: it takes more bits than LSP, > but not by an absurd margin (20%-30% premiun).Another advantage: it can fit more closely to the calculated (by psy) floor, so the psy can be tuned to be a little less pessimistic, so this can save quite some bits in the residue.> Residue 1: Same as residue 0, but uninterleaved. The advantages are > that this is faster and allows one to more easily exploit > adjacent-line structure in the MDCT, assuming that that's what the > codebook model wants to do.Is there any plan to interleave channel 0 and channel 1? This could reduce bitrate somewhat (5-15% in testing), more once we introduce interchannel redundancy into the psy model.> Vorbisfile optimizations; I took HB's optimization patch, fixed a few > infinite loop problems in it, and then decided to go a little nuts > eliminating unneeded machine initializations and decoding work. The > end result is that ov_open (and friends), ov_raw_seek and > ov_pcm_seek_page are more than 100x faster (and even faster than that > on a network file system), and the other seek functions (that do > actually require some internal background PCM decode to get sample > boundaries right) are a shade under 2x faster (again, much larger > margin on distributed file systems).Kudos to the both of you!> I also added an ov_test() function as a fast partial open that > verifies the vorbis-ness of a file (and loads the headers for > perusal), but doesn't seek to learn the chain structure or total > length. A partially open file can then be fully opened using > ov_test_open(). > > Libvorbis now has an official vorbis_packet_blocksize() function to > learn the block size of a packet without decoding it. Libogg also has > one new function, ogg_stream_packetpeek(), which fetches the next > packet in a logical stream without removing it from the stream head. > > None of these changes should affect binary compatability with prebuilt > applications.One can only hope... ;-) Cheers && happy hacking && more applaud etc., Segher --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Hello, Visual C++ 6 Service Pack 5 has problems compiling floor1.c. It complaints about a missing ; after an empty default statement in line 734 of floor1.c. Inserting an additional break solves this, which is what the attached patch does. Regards Ingo <HR NOSHADE> <UL> <LI>application/octet-stream attachment: vorbis-break-patch.diff </UL> -------------- next part -------------- A non-text attachment was scrubbed... Name: vorbis-break-patch.diff Type: application/octet-stream Size: 381 bytes Desc: not available Url : http://lists.xiph.org/pipermail/vorbis-dev/attachments/20010529/a79621c1/vorbis-break-patch-0001.obj