Re: [Lame-dev] strict ISO complience

[Gabriel B. <bou...@mp...>]

> Do you think the user would be willing to do some further tests?

Sorry, but this user only made 2 posts on Roel's forum: 1 for asking for a
solution, and 1 for telling that strict iso compliance worked. So he's not a
regular reader. Moreover, he didn't mentionned his mail address.


>     /* maximum allowed frame size */
>     maxmp3buf = (gfp->strict_ISO) ? 8*960 : 8*2047;
>
> The value of 960 is in my opinion much too restrictive,
> as evidenced by the fact that all software decoders seem to
> have no problems if this value is as large as 2047.

For software, yes, as memory is virtually unlimited. But for hardware, this
is another thing. If I was an hardware manufacturer, I would probably
restrict frame size to the size of a 320k one, as mentionned in iso doc

> For VBR/ABR mode, everytime it uses a 320kbs frame, strict_ISO
> forces us to zero out the reservoir and thus waste bits.

I'm wondering how much average space this is wasting for high bitrate
vbr/abr.

There could be a possibilite to reduce wasted space while preserving strict
iso compliance:

*fully use the frame space. This would lead to main_data_begin=0 in every
frame, and would probably increase complexity (not so much the programming
complexity, but probably the encoding complexity)


But I'm not really sure this would be a good looking solution.

Another thing could be:

*allow 320frames to use bits from the reservoir, but not to use more bits
than a 320k frame. The remaining bits would then be put in the reservoir for
the next frame. I think that this would help for hardware, as it wouldn't
overflow buffer, and it shouldn't reduce quality in a perceptible way.


Regards,

--

Gabriel Bouvigne - France
bou...@mp...
mobile phone: gs...@mp...
icq: 12138873

MP3' Tech: www.mp3-tech.org
personal page: http://gabriel.mp3-tech.org