Why no Vorbis 2-pass? Options

[LCtheDJ]

I see ICL7, optimised for Pentium 4 links for oggenc, oggenc2.1 but not for oggenc2.2.

I figured it out as being
http://homepage.ntlworld.com/jfe1205/oggenc2.2P4.zip

Thanks! You da man!

[Bedeox]

Great work! Now I can increase quality of my files
and my friends will still be able to stream from me!

Another question... are OggEnc daily and OggEnc 2.2 very different?

[schlauf]

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.

You must be lucky and using special input which doesn't produce flaws in the resulting output file. filestamp still says 2003-01-01, and so my files still lack seekability.

try encoding a standard cd track @ 44.1 kHz, 16Bit stereo, and you will encounter the same problems as mentioned above.

therefore i don't quite see why it would make sense to provide a icl7 compiled version.

bye
MS

This post has been edited by species007: Jan 30 2003, 19:03

[john33]

I see ICL7, optimised for Pentium 4 links for oggenc, oggenc2.1 but not for oggenc2.2.

I figured it out as being
http://homepage.ntlworld.com/jfe1205/oggenc2.2P4.zip

Thanks!  You da man!

You're right, sorry, I was in too much of a hurry!! Now corrected.

[DSPguru]

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

it used to be there long time ago (august 2002), but Segher asked me to remove it.

here's a snap from our discussion :

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 remove it.

please 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

[john33]

Great work! Now I can increase quality of my files
and my friends will still be able to stream from me!

Another question... are OggEnc daily and OggEnc 2.2 very different?

oggenc2.2 differs in 3 ways:

1. Providing you have the necessary decoders in 'the path', you can specify lossless encoded files for direct input.

2. You can specify 'padding' in the comment header to be used later for storing tags.

3. You can specify a second pass using the 'rehuff' code which will compress the encoded file with a little more efficiency, ie. make it smaller, without any effect on the quality. Beware, though, this is experimental code and no responsibility is taken for the results!!

[LCtheDJ]

Sorry folks, I must have been spacing out yesterday. Today the .ogg files encoded with the --rehuff option are definitely NOT responding well to search and skip within a file. I can succeed with short skips only, and then only about 3 or 4 skips; after that the search slider jumps back to the start and the track stops playing or the player moves to the next one on the playlist. This is with Winamp 2.81 with the 1.3 alpha input plugin. Yesterday, I could have sworn it was working...

[Bedeox]

Even worse results here... foobar2000 consumes 100% cpu when I try to seek or at the end.

Probably you should remove ALL Vorbis headers after rehuffing then add them again at correct positions.
This should fix seeking/positioning info. I think it breaks because frames change their size unevenly
and most players rely on frame size for seeking... if they get wrong enough info (eg. get wrong header)
they'll either skip the file or crash.

<edit>
This does NOT seems like a bug in OggEnc, but rather in players/libvorbis.
</edit>

This post has been edited by Bedeox: Jan 31 2003, 08:41

[schlauf]

This does NOT seems like a bug in OggEnc, but rather in players/libvorbis.

Sorry, but it indeed does look more like an encoder than an decoder problem. When applying the Graphedit-De-Remuxing procedure as described above, everything works fine and the headers seem to be written in the correct way. (filesize increases by some bytes)

Therefore I agree with you that some not direct-audiodata-related file information tags are not written correctly by oggenc2.2. probably frame/header information - maybe the dev-update also mentioned above will fix it.

bye
MS

[Bedeox]

Libvorbis should recover from such error properly...
Does anybody have a player using decoder other than libvorbis?

If something is not written properly, it could be only last frame.
So problem is in eof() function in libvorbis.
It seems to need padding present in the last frame...
Rehuffing compresses this information.

Remuxing helps because it pads the last frame.

This post has been edited by Bedeox: Jan 31 2003, 09:47

[kheops]

thanks DSPguru, i hope we will see again this 2 pass mode in oggmachine soon

take care

[Garf]

<edit>
This does NOT seems like a bug in OggEnc, but rather in players/libvorbis.
</edit>

Rehuff writes incorrect files (a known problem), so it definetely is an encoder problem.

[Bedeox]

Yes, but are they REALLY incorrect?
I'll check OGG and Vorbis specs and see if this padding is needed
or only 'recommended' or 'might be implemented'.
If it's the second case, then decoder is wrong.

The only wrong call is eof() function, which seems to be used by seek()

<edit>
From Ogg Vorbis I format specification: bitpacking convention

end-of-packet alignment
The 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'.

This is what's probably wrong... the data to skip is rehuffed and zeroes are compressed.
Remuxing restores them. That's why the filesize was different by few bytes.
Decoder (libvorbis) tries to read it and returns end-of-packet.
Winamp handles it correctly (skips), foobar starts to consume 100% CPU...
but after a LONG while it begins to play another file!
It's a bug in foobar, not libvorbis!!!

Nonetheless this data should be restored after rehuffing, it should be quite easy to do.
Just fill the end of the last packet with zeroes where needed after rehuffing.
</edit>

This post has been edited by Bedeox: Jan 31 2003, 11:59

[john33]

Comment from Segher, the author of the rehuff routines, extracted from the vorbis-dev lists:

The best way to speed up its release is fixing the bug in libogg that
prevents it from writing valid streams, btw...



Segher

This dated 08 Nov 2002.

[Bedeox]

Reread my post, I stated what's probably incorrect there.
<edit>
Reread it myself... I'm most probably wrong.
</edit>

What does remuxing exactly do to the track that makes it work?
Someone could duplicate it in oggenc if rehuff is used...
This IS NOT a fix, but rather a proposed workaround.

Oh hell, I don't have the tools and Tobias' page has exceeded bandwith limit...
Anybody can post here two very small files, one only rehuffed and second rehuffed then remuxed?

This post has been edited by Bedeox: Jan 31 2003, 12:34

[Bedeox]

Look at this...
OGG Rehuffed
OGG NOT Rehuffed

This dot is FF... in Rehuffed there are 11 of them, in Non-rehuffed there are 14.

This post has been edited by Bedeox: Jan 31 2003, 12:56

[schlauf]

There's one more bug to report with oggenc 2.2:

when encoding with command line a standard 44.1 kHz, 16 bit, stereo file and "on the fly" downmixing it using the --downmix option, everything works just fine.

additionally using the --rehuff option makes the encoding process crash: the hufftmp-file remains and there is no data in the output file although no error reports.

bye
MS

[Garf]

Rehuff does not work with mono files IIRC.

[john33]

Rehuff does not work with mono files IIRC.

It falls over if the 'residue type' is not = 2. Is that the same thing??? That's point at which it falls over in the rehuff code.

[Garf]

Rehuff does not work with mono files IIRC.

It falls over if the 'residue type' is not = 2. Is that the same thing???

Yes, because Vorbis 1.0 does not use residue2 for mono files.

(I think it can't handle floggy either for similar reasons)

[Bedeox]

Will somebody post here rehuffed and rehuffed/remuxed sample, preferably short?
Or do a binary compare... and give here the results!

<edit>
Just add a safeguard against residue 2 until it's fixed.
</edit>

This post has been edited by Bedeox: Jan 31 2003, 20:05

[callmeace]

I did follow the announcement about Rehuff back in 2002, but I think development was dropped because of 'flags' being set incorrectly (whatever that means ) and there are some bugs in one of the vorbis files that would have to be fixed before Rehuff could be released properly. I was reminded about rehuff when I was encoding a couple of files to vorbis earlier. I didn't think it was ever properly released still although vorbis 101 has been out for a while. I wonder if it ever will be?
I do have an early binary of rehuff on a CD that someone had put up back in 2002 but it is not an official release. It saves about 3% from what I worked out. I think it just looks at Huffy compression and reoptimises it (effectively losslessly to the sound I think)

If anyone knows more about Rehuff and whether it is still being worked on and will ever be released I'd be grateful to know, thanks

[mmortal03]

yeah, I'd like to know too

[Thomas]

Please add 2-pass Vorbis support!

[PatchWorKs]

Up!

Ogg Vorbis constant quality single pass will already give you the best quality the codec can give you for its filesize

Yes, but if i want the best quality (in VBR) for a given filesize ?
I think that a bi-directional 2-pass MT encoder would be great.