Yesterday I downloaded oggenc2.2 and tested it using the --rehuff switch; it seems that skipping and searching within a track is working correctly now.
I see ICL7, optimised for Pentium 4 links for oggenc, oggenc2.1 but not for oggenc2.2.I figured it out as beinghttp://homepage.ntlworld.com/jfe1205/oggenc2.2P4.zipThanks! You da man!
it's a big improvement, i hope we'll see this 2 pass mode in oggmachine soon (for now i only use ogg to convert from ac3 files)thanks
QuoteGreetings Segher,i've understood you're not satisfied with the fact that BeSweet offers ReHuffing of Ogg Vorbis streams.::i would like to keep offering this feature, but would remove it if you want me to. no problem.Please remove it.Quoteplease clarify your position on this issue.When i think the code is ready for public consumption, i'll release it for general use (and for free).Cheers,Segher
Greetings Segher,i've understood you're not satisfied with the fact that BeSweet offers ReHuffing of Ogg Vorbis streams.::i would like to keep offering this feature, but would remove it if you want me to. no problem.
please clarify your position on this issue.
Great work! Now I can increase quality of my filesand my friends will still be able to stream from me!Another question... are OggEnc daily and OggEnc 2.2 very different?
This does NOT seems like a bug in OggEnc, but rather in players/libvorbis.
<edit>This does NOT seems like a bug in OggEnc, but rather in players/libvorbis.</edit>
end-of-packet alignmentThe typical use of bitpacking is to produce many independent byte-aligned packets which are embedded into a larger byte-aligned container structure, such as an Ogg transport bitstream. Externally, each bytestream (encoded bitstream) must begin and end on a byte boundary. Often, the encoded bitstream is not an integer number of bytes, and so there is unused (uncoded) space in the last byte of a packet.Unused space in the last byte of a bytestream is always zeroed during the coding process. Thus, should this unused space be read, it will return binary zeroes.Attempting to read past the end of an encoded packet results in an 'end-of-packet' condition. End-of-packet is not to be considered an error; it is merely a state indicating that there is insufficient remaining data to fulfill the desired read size. Vorbis uses truncated packets as a normal mode of operation, and as such, decoders must handle reading past the end of a packet as a typical mode of operation. Any further read operations after an 'end-of-packet' condition shall also return 'end-of-packet'.
The best way to speed up its release is fixing the bug in libogg that prevents it from writing valid streams, btw... Segher
Rehuff does not work with mono files IIRC.
QuoteRehuff does not work with mono files IIRC.It falls over if the 'residue type' is not = 2. Is that the same thing???
Ogg Vorbis constant quality single pass will already give you the best quality the codec can give you for its filesize