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: 2pass encoding... (Read 5309 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

2pass encoding...

Would such a thing make sense on audio encoding? I mean except for trying to keep the average bitrate on a specified level?

2pass encoding...

Reply #1 –
Quote
Originally posted by Tom Servo
Would such a thing make sense on audio encoding? I mean except for trying to keep the average bitrate on a specified level?

Your 'exception' is the only case I can think of where 2 pass encoding would be useful. I was thinking about 2-pass audio encoding a while back, in connection with movie ripping.  When you rip a movie, you have 2 things to take care of - the audio quality, and the video quality. The traditional thing to do is to transcode the audio to a certain fixed bitrate MP3 (say, 112kbits, if you were compressing quite heavily). Vorbis however compresses natively by *quality* rather than bitrate, so some form of encoding to high quality audio,  and possibly having a second pass to reduce the bitrate, might make sense there.

Similar considerations might come into effect if you're trying to pass audio through a limited bandwidth connection (64kbits ISDN, for example). Compress with Vorbis -q 0, and then while streaming peel to make sure that you never exceed the limit. Of course, you could always use -M 64 while encoding, but only using it while streaming would mean higher quality audio when you were not streaming.

2pass encoding...

Reply #2 –
Dunno, but if it would do a first step, some analyzer code checks the output, and then reencodes with more optimized settings specially for that soundfile.

2pass encoding...

Reply #3 –
I think actually lame has some 2-pass encoding in development.

2pass encoding...

Reply #4 –
Quote
Originally posted by Tom Servo
Dunno, but if it would do a first step, some analyzer code checks the output, and then reencodes with more optimized settings specially for that soundfile.


There is no single "optimized setting" for a soundfile. Every codec with a good VBR implementation and an efficient "standard" setting will continuously adjust itself to guarantee a certain quality (within the limits of the codec and the setting). The result will always be specifically tuned for that particular soundfile.

Analyzing the output for artifacts or acoustical shortcomings would basically require a mathematical model of the human ear. This has been programmed before, but it's a big coding and tuning task of it's own. In several codecs, such as MPC, the "adjustment mechanisms" are already tuned in such a degree that an additional pass would not yield worthwhile quality improvement; it would simply be a waste of time.

2pass encoding...

Reply #5 –
Although quality increases would hardly be significant, couldn't it improve file size while retaining overall quality? Put in a filesize/bitrate one would like to reach and have the codec run through the file making a list of bitrates it would use for each frame and then on the second pass optimizing for that filesize/bitrate.



Could the first pass  be done cbr?  Encode at a target bitrate. then the second pass raises frame bitrate for files that dip into the resivoir too far and lower it for files that don't...
r3mix zealot.

2pass encoding...

Reply #6 –
Vorbis already gives the best quality for the bitrate it can possibly give by using the quality settings. There is no use for 2 pass unless you really must have an ouput file of a specific size. In which case the best thing to do would be to keep adjusting the -q settings and reencoding until you get the filesize you want. You could have a tool to encode once and guess at the -q setting to use, but that may not guarantee the filesize you want in the 2nd pass.

2pass encoding...

Reply #7 –
It was my suspicion that it would only be useful for hitting a target filesize. That is rarely useful except on such occasions as line in encoding where you have several hours of radio show/dictation to take from straight wave and put onto cd. Really a tool for the small masses.
r3mix zealot.

2pass encoding...

Reply #8 –
it's really a useful technique that needs to be used.  When i'm doing dvd rips it's of the utmost importance to hit file sizes dead on and now xvid can predict a file within half a meg (50k most of the time).  It would be helpful to have audio of the same preciseness .

2pass encoding...

Reply #9 –
Heh... It does make sense... You know exactly how much video you have, but you have to monkey around to get the audio to be the right size to fill up the last portion of the cd. Nor will you be able to use the same setting for everything.

I suppose just do your audio at a bitrate that is A. Transparent or B. Enough for the situation then plan your video file size around it. Works out pretty well I think.
r3mix zealot.

2pass encoding...

Reply #10 –
Then do it the way everyone else is doing. Encode the audio first at a -q value you like, obtain the the output filesize, subtract it from the size of your CD to obtain the XviD target filesize. If you use Gordian Knot to calculate bitrate, enable Frame Overhead Calculations but set it to "No audio", assuming you are using OGM which has very little frame overhead. I get exactly 700mb for my past few rips this way.

2pass encoding...

Reply #11 –
I think that encoding this way gives you more flexibility anyway. Over Audio anyway. Because you are using filesize prediction in video you take what you are given.


One question though. Would it not be possible to have a tool perhaps based on lame that ran through the file at the quality specified and told you what you file size output would be? Instead of actually encoding the file it would just specify which bitrate it would use before encoding and skip to the next frame?
r3mix zealot.

2pass encoding...

Reply #12 –
Indicating the bitrate is nearly the same as encoding for an encoder.

What can be done is : create a frontend that would create a reduced wave (just keep some portions), encode it, and indicate the bitrate.

This would give you a "preview" of the final bitrate. All the trick is to reduce the original wave in a smart way.

2pass encoding...

Reply #13 –
imho 2 pass encoding in audio is pretty much useless, if you wanna mux the file with video, just make audio first and see whats left ... (the new mpeg4 'derivates' dont really get of the predicted average bitrate anymore as was the case with divx 3.11 for example), would be nice to make some sort of 2pass decoding tho, to avoid the clipping done in decoder step (dont know how is that handled by lame --decode?).

edit: oh, pls dont sell the rg story in this context  B)
PANIC: CPU 1: Cache Error (unrecoverable - dcache data) Eframe = 0x90000000208cf3b8
NOTICE - cpu 0 didn't dump TLB, may be hung

2pass encoding...

Reply #14 –
Would it be simple to instead of creating an actual file  instead create a file that has how many frames what bitrate and filesize came from your settings? I'm not sure it would be useful, but ease of creating?
r3mix zealot.

2pass encoding...

Reply #15 –
What you are talking about is perceptual entropy measurements. It can be helpful but not accurate, since filesize still depend on how the encoder encodes entropy.

2pass encoding...

Reply #16 –
I read something about rehuff in conjunction with 2pass encoding. Is rehuff true two pass or does it only calculate the huffman divide twice?
r3mix zealot.

2pass encoding...

Reply #17 –
rehuff is something you can apply on a second pass. it calculates the optimal huffman table for the track to improve the bit packing efficiency.