IPB

Welcome Guest ( Log In | Register )

3 Pages V  < 1 2 3 >  
Reply to this topicStart new topic
Why no Vorbis 2-pass?
LCtheDJ
post Jan 30 2003, 18:44
Post #26





Group: Members
Posts: 108
Joined: 14-November 02
Member No.: 3778



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!
Go to the top of the page
+Quote Post
Bedeox
post Jan 30 2003, 18:45
Post #27





Group: Members
Posts: 246
Joined: 20-December 02
From: Quite quiet place in Poland
Member No.: 4181



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)
Go to the top of the page
+Quote Post
schlauf
post Jan 30 2003, 18:48
Post #28





Group: Members
Posts: 92
Joined: 7-September 02
From: Germany
Member No.: 3321



QUOTE (LCtheDJ @ Jan 30 2003 - 06:59 PM)
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
Go to the top of the page
+Quote Post
john33
post Jan 30 2003, 19:14
Post #29


xcLame and OggDropXPd Developer


Group: Developer
Posts: 3760
Joined: 30-September 01
From: Bracknell, UK
Member No.: 111



QUOTE (LCtheDJ @ Jan 30 2003 - 05:44 PM)
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.


--------------------
John
----------------------------------------------------------------
My compiles and utilities are at http://www.rarewares.org/
Go to the top of the page
+Quote Post
DSPguru
post Jan 30 2003, 19:18
Post #30


BeSweet Developer


Group: Developer
Posts: 235
Joined: 14-December 01
From: sitting on top of a supercompact cardinal
Member No.: 643



QUOTE (kheops @ Jan 1 2003 - 03:31 PM)
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 (Segher @ Oct 29 2002 - 01:34 PM)
QUOTE (DSPguru @ Oct 28 2002 - 20:09 PM)

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 (DSPguru @ Oct 28 2002 - 20:09 PM)
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


--------------------
DSPguru's Webpage - home of BeSweet & The OggMachine.
BeSplit - 7kb of A loseless AC3/AAC/MP3/MP2/WAV Cutter :)
Go to the top of the page
+Quote Post
john33
post Jan 30 2003, 19:19
Post #31


xcLame and OggDropXPd Developer


Group: Developer
Posts: 3760
Joined: 30-September 01
From: Bracknell, UK
Member No.: 111



QUOTE (Bedeox @ Jan 30 2003 - 05:45 PM)
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!! wink.gif


--------------------
John
----------------------------------------------------------------
My compiles and utilities are at http://www.rarewares.org/
Go to the top of the page
+Quote Post
LCtheDJ
post Jan 30 2003, 19:35
Post #32





Group: Members
Posts: 108
Joined: 14-November 02
Member No.: 3778



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...
Go to the top of the page
+Quote Post
Bedeox
post Jan 31 2003, 08:22
Post #33





Group: Members
Posts: 246
Joined: 20-December 02
From: Quite quiet place in Poland
Member No.: 4181



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


--------------------
I've changed only because of myself.
Remember, when you quote me, you're quoting AstralStorm.
(read: this account is dead)
Go to the top of the page
+Quote Post
schlauf
post Jan 31 2003, 08:47
Post #34





Group: Members
Posts: 92
Joined: 7-September 02
From: Germany
Member No.: 3321



QUOTE (Bedeox @ Jan 31 2003 - 09:22 AM)
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
Go to the top of the page
+Quote Post
Bedeox
post Jan 31 2003, 09:40
Post #35





Group: Members
Posts: 246
Joined: 20-December 02
From: Quite quiet place in Poland
Member No.: 4181



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


--------------------
I've changed only because of myself.
Remember, when you quote me, you're quoting AstralStorm.
(read: this account is dead)
Go to the top of the page
+Quote Post
kheops
post Jan 31 2003, 10:54
Post #36





Group: Members
Posts: 56
Joined: 8-April 02
Member No.: 1724



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

take care
Go to the top of the page
+Quote Post
Garf
post Jan 31 2003, 11:17
Post #37


Server Admin


Group: Admin
Posts: 4884
Joined: 24-September 01
Member No.: 13



QUOTE (Bedeox @ Jan 31 2003 - 09:22 AM)
<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.
Go to the top of the page
+Quote Post
Bedeox
post Jan 31 2003, 11:28
Post #38





Group: Members
Posts: 246
Joined: 20-December 02
From: Quite quiet place in Poland
Member No.: 4181



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>

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


--------------------
I've changed only because of myself.
Remember, when you quote me, you're quoting AstralStorm.
(read: this account is dead)
Go to the top of the page
+Quote Post
john33
post Jan 31 2003, 11:51
Post #39


xcLame and OggDropXPd Developer


Group: Developer
Posts: 3760
Joined: 30-September 01
From: Bracknell, UK
Member No.: 111



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.


--------------------
John
----------------------------------------------------------------
My compiles and utilities are at http://www.rarewares.org/
Go to the top of the page
+Quote Post
Bedeox
post Jan 31 2003, 11:53
Post #40





Group: Members
Posts: 246
Joined: 20-December 02
From: Quite quiet place in Poland
Member No.: 4181



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


--------------------
I've changed only because of myself.
Remember, when you quote me, you're quoting AstralStorm.
(read: this account is dead)
Go to the top of the page
+Quote Post
Bedeox
post Jan 31 2003, 12:55
Post #41





Group: Members
Posts: 246
Joined: 20-December 02
From: Quite quiet place in Poland
Member No.: 4181



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


--------------------
I've changed only because of myself.
Remember, when you quote me, you're quoting AstralStorm.
(read: this account is dead)
Go to the top of the page
+Quote Post
schlauf
post Jan 31 2003, 18:23
Post #42





Group: Members
Posts: 92
Joined: 7-September 02
From: Germany
Member No.: 3321



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
Go to the top of the page
+Quote Post
Garf
post Jan 31 2003, 18:33
Post #43


Server Admin


Group: Admin
Posts: 4884
Joined: 24-September 01
Member No.: 13



Rehuff does not work with mono files IIRC.
Go to the top of the page
+Quote Post
john33
post Jan 31 2003, 19:24
Post #44


xcLame and OggDropXPd Developer


Group: Developer
Posts: 3760
Joined: 30-September 01
From: Bracknell, UK
Member No.: 111



QUOTE (Garf @ Jan 31 2003 - 05:33 PM)
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.


--------------------
John
----------------------------------------------------------------
My compiles and utilities are at http://www.rarewares.org/
Go to the top of the page
+Quote Post
Garf
post Jan 31 2003, 19:37
Post #45


Server Admin


Group: Admin
Posts: 4884
Joined: 24-September 01
Member No.: 13



QUOTE (john33 @ Jan 31 2003 - 08:24 PM)
QUOTE (Garf @ Jan 31 2003 - 05:33 PM)
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)
Go to the top of the page
+Quote Post
Bedeox
post Jan 31 2003, 20:01
Post #46





Group: Members
Posts: 246
Joined: 20-December 02
From: Quite quiet place in Poland
Member No.: 4181



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


--------------------
I've changed only because of myself.
Remember, when you quote me, you're quoting AstralStorm.
(read: this account is dead)
Go to the top of the page
+Quote Post
callmeace
post Mar 25 2004, 03:11
Post #47





Group: Members
Posts: 54
Joined: 20-March 04
Member No.: 12869



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 unsure.gif ) 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 cool.gif
Go to the top of the page
+Quote Post
mmortal03
post Mar 25 2004, 17:25
Post #48





Group: Members
Posts: 601
Joined: 19-July 02
From: USA
Member No.: 2667



yeah, I'd like to know too wink.gif


--------------------
WARNING: Changing of advanced parameters might degrade sound quality. Modify them only if you are expirienced in audio compression!
Go to the top of the page
+Quote Post
Thomas
post Jul 21 2004, 09:25
Post #49





Group: Banned
Posts: 9
Joined: 19-July 04
Member No.: 15601



Please add 2-pass Vorbis support!
Go to the top of the page
+Quote Post
PatchWorKs
post Aug 18 2006, 17:15
Post #50





Group: Members
Posts: 498
Joined: 2-October 01
Member No.: 168



Up! tongue.gif

QUOTE (tangent @ Jan 1 2003, 12:10) *
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. blink.gif
Go to the top of the page
+Quote Post

3 Pages V  < 1 2 3 >
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 21st August 2014 - 08:11