Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Why no Vorbis 2-pass? (Read 26931 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Why no Vorbis 2-pass?

Reply #26
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?
I've changed only because of myself.
Remember, when you quote me, you're quoting AstralStorm.
(read: this account is dead)

Why no Vorbis 2-pass?

Reply #27
Quote
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

Why no Vorbis 2-pass?

Reply #28
Quote
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.

Why no Vorbis 2-pass?

Reply #29
Quote
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 :

Quote
Quote

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.

Quote
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

Why no Vorbis 2-pass?

Reply #30
Quote
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!!

Why no Vorbis 2-pass?

Reply #31
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...

Why no Vorbis 2-pass?

Reply #32
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>
I've changed only because of myself.
Remember, when you quote me, you're quoting AstralStorm.
(read: this account is dead)

Why no Vorbis 2-pass?

Reply #33
Quote
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

Why no Vorbis 2-pass?

Reply #34
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.
I've changed only because of myself.
Remember, when you quote me, you're quoting AstralStorm.
(read: this account is dead)

Why no Vorbis 2-pass?

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

take care

Why no Vorbis 2-pass?

Reply #36
Quote
<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.

Why no Vorbis 2-pass?

Reply #37
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
Quote
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>
I've changed only because of myself.
Remember, when you quote me, you're quoting AstralStorm.
(read: this account is dead)

Why no Vorbis 2-pass?

Reply #38
Comment from Segher, the author of the rehuff routines, extracted from the vorbis-dev lists:
Quote
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.

Why no Vorbis 2-pass?

Reply #39
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?
I've changed only because of myself.
Remember, when you quote me, you're quoting AstralStorm.
(read: this account is dead)

Why no Vorbis 2-pass?

Reply #40
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.
I've changed only because of myself.
Remember, when you quote me, you're quoting AstralStorm.
(read: this account is dead)

Why no Vorbis 2-pass?

Reply #41
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

Why no Vorbis 2-pass?

Reply #42
Rehuff does not work with mono files IIRC.

Why no Vorbis 2-pass?

Reply #43
Quote
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.

Why no Vorbis 2-pass?

Reply #44
Quote
Quote
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)

 

Why no Vorbis 2-pass?

Reply #45
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>
I've changed only because of myself.
Remember, when you quote me, you're quoting AstralStorm.
(read: this account is dead)

Why no Vorbis 2-pass?

Reply #46
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 

Why no Vorbis 2-pass?

Reply #47
yeah, I'd like to know too
WARNING:  Changing of advanced parameters might degrade sound quality.  Modify them only if you are expirienced in audio compression!

Why no Vorbis 2-pass?

Reply #48
Please add 2-pass Vorbis support!

Why no Vorbis 2-pass?

Reply #49
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.