Does it glance over the whole song first off, at high speed, and determine areas of "needs more than the average" and "needs less than the average"?
Or does it take a few seconds into account, and uses more than specified bitrate when it first needs to, and then searches for a less than specified bitrate for the next part? What if it has used more than specified too much, and cant make a sacrifice to less than specified within the area it is studying? Will it check over that area again, using specified as much as possible?
It intrigues me...
Full Version: Lame ABR
IIRC, abr uses the same masking tables as cbr, which are based on something called perceptual entropy. What that is I am not sure.
These tables will call for a certain bitrate per frame to properly mask the q noise.
If you are creating a 160 cbr stream, and the tables require a bitrate of 192, the bit reservoir will be used to make up the difference. If the bit reservoir is empty or insufficient, then too bad, too sad.
With abr, the bit reservoir is disabled or actually made infinite, so that if 192 is required it will just create a 192 frame, or 256, 320, whatever.
As a starting point, I think it was 80 percent of frames are assigned to the specified bitrate in order to stay around the average specified by the user.
It seems to me that it was Gabriel that was answering most of the ABR questions back when it was newer and people were more interested in it. he could provide better info I'm sure.
I read somewhere, I think it was the sulaco home page that the vbr in FhG is actually a form of abr.
hope that helps
These tables will call for a certain bitrate per frame to properly mask the q noise.
If you are creating a 160 cbr stream, and the tables require a bitrate of 192, the bit reservoir will be used to make up the difference. If the bit reservoir is empty or insufficient, then too bad, too sad.
With abr, the bit reservoir is disabled or actually made infinite, so that if 192 is required it will just create a 192 frame, or 256, 320, whatever.
As a starting point, I think it was 80 percent of frames are assigned to the specified bitrate in order to stay around the average specified by the user.
It seems to me that it was Gabriel that was answering most of the ABR questions back when it was newer and people were more interested in it. he could provide better info I'm sure.
I read somewhere, I think it was the sulaco home page that the vbr in FhG is actually a form of abr.
hope that helps
Abr is using the same algo as cbr, but with an unlimited bit reservoir.
It does not try to actively enforce the target bitrate.
It does not try to actively enforce the target bitrate.
QUOTE(Gabriel @ Jul 4 2003, 12:37 AM)
Abr is using the same algo as cbr, but with an unlimited bit reservoir.
It does not try to actively enforce the target bitrate.
It does not try to actively enforce the target bitrate.
Doesn't that somewhat defeat the purpose of abr? If it doesn't try to strictly enforce the target bitrate, doesn't that make it a form of VBR with a different algorithm?
No, because it is trying to match the desired bitrate.
It targets 90% of the bitrate, and depending of bit reservoir demands (which is considered to be unlimited when using abr) can use bigger frames.
But it is not actively trying to enforce the target bitrate. This means that some hard to encode tracks (like fatboy) can produce a bitrate quite bigger than what you asked for.
Overall, the resulting bitrate should be in the range of the one you requested.
It targets 90% of the bitrate, and depending of bit reservoir demands (which is considered to be unlimited when using abr) can use bigger frames.
But it is not actively trying to enforce the target bitrate. This means that some hard to encode tracks (like fatboy) can produce a bitrate quite bigger than what you asked for.
Overall, the resulting bitrate should be in the range of the one you requested.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.