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: halb wahrheiten (Read 2026 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

halb wahrheiten

Quote
Older version used the bit reservoir, even at 320kbps.
You can always save bits for the reservoir, whatever the bitrate. The problem is the the number of bits really used for a frame is limited to the size of a 320kbps frame. So in 320kbps cbr, if you save some bits into the reservoir, you will no be able to use them to have additional bits for some other frames.
[a href="index.php?act=findpost&pid=336507"][{POST_SNAPBACK}][/a]

I was busy with other things but now I'm back to my mp3 how to use it decision problem.
I've been reading quite a lot about mp3 technology, especially on bit reservoir and ISO standard interpretation problems.

After having read this I do not understand your answer. My understanding is like this:

I don't have a copy of the ISO standard, but from posts here on HA and other information there are two issues with ISO standard. Taking the ISO statements the worst possible way they say

a) frame buffer size in the decoder must be no more than 7680 bit
b) encoders have to set the main_data-begin value for 320 kbps frames to 0.

a) seems to be explicitly addressed in favor of a definite buffer size for decoder design.
However the ISO fathers seem to have done a bad job here because 7680 bit is the frame size of a 320 kbps frame sampled with 48 kHz. A 44.1 or 32 kHz sampled  320 kbps frame however does not fit within 7680 bit.
So taking 7680 bit as a frame size limit means an encoder can use only 7680 bit within a 44.1 kHz sampled 320 kbps frame which is quite a big waste. Depending on implementation 7680 bit frame size limited decoders might be even unable to use 320 kbps frames at all.
Moreover bit reservoir usage is strongly limited on 256 kbps frames when taking the 7680 bit frame buffer limit the most restrictive way.
On the other hand maximum buffer size for any real frame situation is 11520 bit (frame size of a 32 kHz sampled 320 kbps frame) + 4088 bit (bit reservoir) only, and this is no problem for any software decoder and nowadays shouldn't be a problem when developing a hardware decoder.
Thus igoring the 7680 bit frame buffer limit as for example Lame does (without the ISO option) is considered to be no problem for most decoders. For software decoders (also used with DAPs like the iRiver H1xx, H3xx, Cowon iAudio X5) it is hard to believe that the 7680 bit limit is an issue.

b) makes no sense whatsoever. The best sense I can give it is a thinking like this:
in a cbr320 mp3 file with 48 kHz sampling freq each real frame fits exactly into the 'physical' 320 kbps frame. Bit reservoir is useless because of the 7680 bit frame buffer limitation thus making encoding task a little bit easier. This corresponds to setting main_data-begin always to 0. This argument however is valid at most for stricht cbr usage. With variable bit rate frames there are suituations where bit reservoir can be used with advantage on 320 kbps frames even when respecting the 7680 bit limit.
As for the decoder side b) isn't a simplification. It is hard to believe that a decoder expects the frame to begin at another place than is told by the main_data-begin value of the current frame. Using the main_data-begin value is not a contradichtion towards b). If b) is a problem this means a decoder would explicitly treat 320 kbps frames in a specific way, that is not using the main_data-begin value but implicitly taking it as 0. This means extra coding which is not necessary.
Taking it all together b) is at best a simplifying suggestion for the encoder design with cbr320 usage on the background of a).

As for encoder design a) is a slight issue and b) should be an even slighter one as for my understanding.

That's why I do not understand why you ignore a) but you do not ignore b) as I've learnt from several posts here and on sourceforge.

As for 3.90.3 and EncSpot it is hard to beleive that EncSpot gives another information on bit reservoir than average and maximum main_data-begin value of the frames. And with this it is hard to believe that each real frame begins at the start of the actual frame in contradiction to the main_data-begin value.

So as for my understanding 3.90.3 does make efficient use of the bit reservoir.

This is quite essential as it makes real 476 kbps frames possible with cbr320. And it's a good explanation why 3.90.3 cbr320 performs better than 3.96+ as bit reservoir is not used with 3.96+ cbr320 limiting real framerate to 320 kbps.
lame3995o -Q1.7 --lowpass 17
 

halb wahrheiten

Reply #1 –
Please, do not post your interpretation of the ISO standard without actually reading it.
You are just posting misinformation in this case.