IPB

Welcome Guest ( Log In | Register )

3 Pages V   1 2 3 >  
Reply to this topicStart new topic
Why no Vorbis 2-pass?
Phaedras
post Dec 31 2002, 13:59
Post #1





Group: Members
Posts: 32
Joined: 3-October 02
From: Somerville, MA
Member No.: 3476



I know this question has been brought up before, most specifically on the Vorbis mailing list, but I still don't quite understand why 2-pass encoding isn't supported by Oggenc. Sure, the savings are minimal, but isn't that what lossy coding is all about? To make every bit count?
Go to the top of the page
+Quote Post
Benjamin Lebsanf...
post Dec 31 2002, 14:06
Post #2





Group: Members
Posts: 761
Joined: 29-September 01
Member No.: 40



maybe in the future rehuff could be integrated, maybe john can create a special version rolleyes.gif biggrin.gif
Go to the top of the page
+Quote Post
john33
post Dec 31 2002, 14:24
Post #3


xcLame and OggDropXPd Developer


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



On a single example, rehuff compresses a 6016Kb file to 5925Kb. The saving is about 3kbps on this file encoded at -q 6.25. It would not be difficult to integrate this as an option into oggenc2.1 (my hybrid with lossless decoding support), but is there really a demand for it? unsure.gif


--------------------
John
----------------------------------------------------------------
My compiles and utilities are at http://www.rarewares.org/
Go to the top of the page
+Quote Post
Benjamin Lebsanf...
post Dec 31 2002, 14:28
Post #4





Group: Members
Posts: 761
Joined: 29-September 01
Member No.: 40



it would be a nice feature to play with and if its not too difficult go ahead, we would love it smile.gif
QUOTE
Because of the sub-optimal one pass method, it is possible to gain some space by recompressing an Ogg Vorbis file, but space savings as dramatic as 10% could not be reproduced with the current version of the encoder. (For example, a quick test by myself resulted in a pitiful 0.2% gain on a randomly chosen file from my collection.)

Segher Boessenkool is currently developing a tool that optimizes the Huffman codes for a given Ogg Vorbis file in order to shave off a few percent of the file size. He reports that the resulting space savings are normally under 5%, and typically between 1% and 2%.
Go to the top of the page
+Quote Post
robUx4
post Dec 31 2002, 15:12
Post #5


Matroska Developer


Group: Developer (Donating)
Posts: 410
Joined: 14-March 02
From: Paris
Member No.: 1519



In video, double pass is not used for saving space, but to maximize quality for a given size/bitrate. I think it should be the same for audio.


--------------------
http://www.matroska.org/ : the best vapourware / http://robux4.blogspot.com/
Go to the top of the page
+Quote Post
Tripwire
post Dec 31 2002, 15:56
Post #6





Group: Members
Posts: 156
Joined: 28-December 02
Member No.: 4272



I don't know if this is doable, but a 2nd pass could scan the compressed file for heavy compression damages and reencode the block with a higher bitrate. And do the same on highbitrate blocks, recompressing them on a lower bitrate.
Go to the top of the page
+Quote Post
Slo Mo Snail
post Dec 31 2002, 16:02
Post #7





Group: Members
Posts: 111
Joined: 2-July 02
From: Germany
Member No.: 2450



How do you want to detect artefacts? There's no way to teach a computer, how an artefact "looks" like
Go to the top of the page
+Quote Post
amp
post Dec 31 2002, 16:41
Post #8





Group: Members
Posts: 61
Joined: 30-December 01
From: Buenos Aires
Member No.: 837



QUOTE
I don't know if this is doable, but a 2nd pass could scan the compressed file for heavy compression damages and reencode the block with a higher bitrate. And do the same on highbitrate blocks, recompressing them on a lower bitrate.


No, I think the problem is more or less like this: The 2nd pass is really worth only with ABR-like bitrate managment. With video codecs like DivX or Xvid most of the times you're targeting for a certain bitrate, much like LAME ABR. So the problem is: if the codec, as it only 'knows' the complexity of the signal progressively, wastes too much bits with the first sections of the movie or the audio, there'll less space for the later part. And, if the codec is conservative at the first part 'waiting' for more complex signals, maybe at the end it'll never get that complex signals so, again, bits are wasted.

So, at the first pass the encoder only analyzes the complexity of the signal (therefore the first pass is much faster than the second) for a correct 'bit distribution' at the second pass.

I think the method discused here for Vorbis is other, that is in relation with Huffman compression (lossless).

Excuse me if this explanation is poor technically speaking, or incorrect. Maybe someone can explain it better than me smile.gif .

This post has been edited by amp: Dec 31 2002, 16:43
Go to the top of the page
+Quote Post
john33
post Dec 31 2002, 18:26
Post #9


xcLame and OggDropXPd Developer


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



@amp: Your explanation is perfectly understandable to me. wink.gif

The other comment about 2 pass and quality, since most people concerned with quality use the quality settings, and these use VBR, the encoder grabs whatever bits it needs to achieve the desired quality level in the first place.


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





Group: Members
Posts: 674
Joined: 29-September 01
Member No.: 63



QUOTE (robUx4 @ Dec 31 2002 - 10:12 PM)
In video, double pass is not used for saving space, but to maximize quality for a given size/bitrate. I think it should be the same for audio.

Actually in video, the main purpose of 2-pass is to obtain a target output filesize after encoding while keeping quality consistent through the entire video. The one-pass method of obtaining a target output filesize (CBR) gives too many bits to the easy scenes and too few bits to the hard scenes therefore quality noticably suffers in the hard scenes. 2-pass allows target filesize to be reached while maintaining a consistent quality.

In video, a target output filesize is often desired because people often rip DVDs to CDRs and target the maximum capacity of 1 or 2 CDRs. In audio, 2-pass is not really in demand because it would be very rare that an audio ripper would require a target filesize for the encoding.

Ogg Vorbis constant quality single pass will already give you the best quality the codec can give you for its filesize (not counting the use of rehuff), it is just that the output filesize is unpredictable. Video encoding can also be done with a constant quality by encoding with a constant quantizer (option available for xvid and divx4/5), as usual, filesize is unpredictable, but this is the recommended method where you do not need a target filesize.

The other factor why you don't see 2-pass audio encoding is that it's harder to implement than for video. In video, there is only 1 variable (quantizer) which is varied between frames to affect the size of the frame towards a target bitrate. For audio, there are a lot more variables which the encoder will have to consider.


Audio encoding 2-pass has been asked many times before, it really should go into a FAQ. Pio2001, you there? smile.gif
Go to the top of the page
+Quote Post
Mgz
post Jan 1 2003, 11:20
Post #11





Group: Members
Posts: 155
Joined: 11-December 02
From: Alberta
Member No.: 4049



WMAv9 support 2-pass encoding,too unsure.gif unsure.gif blink.gif blink.gif

/me ph34r.gif ph34r.gif


--------------------
still LAME 3.96.1 --preset extreme -q 0 -V 0 -m s at least until 2005.
Go to the top of the page
+Quote Post
Mac
post Jan 1 2003, 12:00
Post #12





Group: Members
Posts: 650
Joined: 28-July 02
From: B'ham UK
Member No.: 2828



Going back to john33, saving 3kbs is exactly what it's about smile.gif You could do it like that, just shaving the file-size down.. you still have the quality defined by q6.25, but in a smaller file size.

If it was the size you were after, you can just encode slightly higher at q6.4, and get 3kbs more of quality added for the file you were expecting smile.gif


--------------------
< w o g o n e . c o m / l o l >
Go to the top of the page
+Quote Post
dev0
post Jan 1 2003, 12:08
Post #13





Group: Developer
Posts: 1679
Joined: 23-December 01
From: Germany
Member No.: 731



Besides from the various problems reported about rehuff at the Doom9 forums, I'd definetly like tosee this function in oggenc2.1.
But don't call it 2 Pass! As explained above the meaning of 2pass is different from what rehuff does, so adding an option --rehuff might be just fine.
dev0


--------------------
"To understand me, you'll have to swallow a world." Or maybe your words.
Go to the top of the page
+Quote Post
john33
post Jan 1 2003, 12:37
Post #14


xcLame and OggDropXPd Developer


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



For those who are interested, oggenc2.2 is now available from Mirror 1. rolleyes.gif

Additional option is '--rehuff'. It processes quite quickly with a fair amount of info displayed to the console. The '-Q' (quiet) option from the command line will also kill the console output from the rehuff pass.

Have fun!! wink.gif


--------------------
John
----------------------------------------------------------------
My compiles and utilities are at http://www.rarewares.org/
Go to the top of the page
+Quote Post
kheops
post Jan 1 2003, 13:31
Post #15





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



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
Go to the top of the page
+Quote Post
sven_Bent
post Jan 1 2003, 14:02
Post #16





Group: Members
Posts: 691
Joined: 15-December 01
From: Denmark
Member No.: 655



does the ogg vidoe container support the rehuff savings ?

if i use ogmmux to mux avi videi and some vorbis file with rehuff

is the audio still done with the rehuff savings ?


--------------------
Sven Bent - Denmark
Go to the top of the page
+Quote Post
john33
post Jan 1 2003, 14:19
Post #17


xcLame and OggDropXPd Developer


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



QUOTE (sven_Bent @ Jan 1 2003 - 01:02 PM)
does the ogg vidoe container support the rehuff savings ?

if i use ogmmux to mux avi videi and some vorbis file with rehuff

is the audio still done with the rehuff savings ?

So far as I'm aware, the content and appearance of the rehuffed file to 'ogg aware' software should be no different than for any other ogg file. All the headers are correct, it simply has more efficient compression. I know that this is not an unequivocal answer, but I don't believe it should behave in any different way to any other ogg file.


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





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



OK, now I post it here.

I just tried the --rehuff option while ripping and encoding a whole audio CD - nothing special about that.
For ripping I use Exact Audio Copy in conjunction with OggEnc2, command line reads as follows:

-q 6 %s %d -t "%t" -a "%a" -l "%g" -d "%y" -N "%n" -G "%m" --rehuff

This has worked well so far except the --rehuff option.

Now, having tried to encode this CD, I have indeed received files which were smaller than they used to when using OggEnc(1), but unfortunately, seeking and jumping in files has been corrupted.

For playback I use Winamp 2.81 and in_vorbis.dll 1.2.9 latest build.

When trying to seek inside the file to any position after half of the whole file right after starting, playback instantly stops.

Did anybody else track this problem down? It would be interesting if it is an encoder or decoder problem ... and, strangely, it didn't occur on ALL files, just on about 20% ...

Bye
MS

EDIT: OK, now I've found out at the Doom9 Forum that this problem has been encountered in previous releases too ... unfortunately there seems to be no solution, right?

http://forum.doom9.org/showthread.php?thre...ighlight=rehuff

This post has been edited by species007: Jan 1 2003, 16:35
Go to the top of the page
+Quote Post
S_O
post Jan 1 2003, 17:21
Post #19





Group: Members
Posts: 296
Joined: 27-July 02
From: Germany
Member No.: 2821



QUOTE
Now, having tried to encode this CD, I have indeed received files which were smaller than they used to when using OggEnc(1), but unfortunately, seeking and jumping in files has been corrupted.

Yes, I noticed the same problem with all players.
QUOTE
EDIT: OK, now I've found out at the Doom9 Forum that this problem has been encountered in previous releases too ... unfortunately there seems to be no solution, right?

I found a solution: remux the file (not reencode!) with Tobias DirectShow-filters, build a graph in GraghEdit: infile.ogg -> Ogg Splitter -> Ogg Multiplexer -> outfile.ogg
The file has nearly the same size (27 Byte bigger actually) but seeking works perfect again.
QUOTE
does the ogg vidoe container support the rehuff savings ? if i use ogmmux to mux avi videi and some vorbis file with rehuff is the audio still done with the rehuff savings ?

Yes. My test:
without rehuff: 1.458.758 Byte
with rehuff: 1.409.311 Byte (96,610% from the normal file) seeking is broken!
with rehuff and remuxed: 1.409.338 Byte (96,612% from the normal file) file perfectly seekable!

So this problem is not unfixable and not a general result of rehuffing.
Go to the top of the page
+Quote Post
john33
post Jan 1 2003, 17:25
Post #20


xcLame and OggDropXPd Developer


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



Hmmm, I can't comment at this time other than to confirm the same behaviour. The files play fine from start to finish, it's the seeking that screws up. unsure.gif


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





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



Yeah, that GraphEdit-Thingo works indeed. Unfortunately, this procedure is way too complex to apply it to a whole bunch of .OGG files, so I do hope this issue can be handled very soon ....

Thanks John, we appreciate your effort!
Go to the top of the page
+Quote Post
john33
post Jan 2 2003, 23:06
Post #22


xcLame and OggDropXPd Developer


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



BTW, I was just trawling through the vorbis-dev mailing lists and came across a comment by Segher Boessenkool, the author of rehuff, referring to a bug in Libogg as being the cause of the problems. The upcoming patch release relates primarily to the ogg side of things, ogg file I believe, so maybe this will enable a proper release of rehuff in the not too distant future.


--------------------
John
----------------------------------------------------------------
My compiles and utilities are at http://www.rarewares.org/
Go to the top of the page
+Quote Post
rc55
post Jan 6 2003, 01:32
Post #23





Group: Members
Posts: 366
Joined: 15-October 01
From: Exeter, UK.
Member No.: 300



John,

It seriously makes me bang my head against the wall - you are so bloody helpful!
It's very much a case of "It'd be nice if vorbis did...." and before I've finished the
sentence you've gone and done it. Superb.

I'll have to come to Berkshire and buy lots of beer for you.

Ruairi.


--------------------
rc55.com - nothing going on
Go to the top of the page
+Quote Post
LCtheDJ
post Jan 30 2003, 17:59
Post #24





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



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.

My filesize savings due to using --rehuff came to about 1 - 2 percent.

Are there plans to make available an ICL7 compile optimised for Pentium 4?

My thanks to john33!
Go to the top of the page
+Quote Post
john33
post Jan 30 2003, 18:17
Post #25


xcLame and OggDropXPd Developer


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



QUOTE (LCtheDJ @ Jan 30 2003 - 04: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.

My filesize savings due to using --rehuff came to about 1 - 2 percent.

Are there plans to make available an ICL7 compile optimised for Pentium 4?

My thanks to john33!

No sooner requested, than done! wink.gif You'll find it at Mirror 1.


--------------------
John
----------------------------------------------------------------
My compiles and utilities are at http://www.rarewares.org/
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: 22nd July 2014 - 14:55