[Scummvm-devel] Idea: IndexedMp3AudioStream

yotam barnoy yotambarnoy at gmail.com
Fri Oct 8 16:55:09 CEST 2010


Just to try and calculate the errors we'll have with XING, off the top
of my head... Anybody feel free to correct me since I did this really
quickly (since I won't have internet access until Saturday night):

100 is what we divide by in the time domain, since we take a data
point every 100th of the time. This error is correctable, because we
can seek until we get to the true time point we want.

The data size should be divided by 256, since we're encoding a data
offset with 8 bits. This error is not correctable. A 30MB file divided
by 256 gives a maximum error of 30,000,000 / 256 = 117,187 ~ 117KB. So
we can be off by as much as 117KB!!
To get an idea of the error, we usually sample at 22khz and each
sample is 16 bits so normal PCM data is 44KB per second. Let's say our
VBR MP3 is about 3 times more efficient on average, so we have 44/3 =
15KB/second. This means we could be off by as much as (117/15) = 8
seconds!!!

To see what the error would be with ASPI using 16bits, we divide 30MB
by 16556 to get
30,000,000 / 16556 ~ 1812 ie 1.8KB. Assuming the same data rate for
the MP3, we get (1.8/15) ~ 0.1seconds or 100 msecs. Are we happy with
this kind of delay? This is pretty close to the MP3 frame resolution,
so trying to outdo this may not be worth it.

If we are happy with it, we can use ASPI. If we're not, we can define
our own ID3 tags -- there are tags available for 'experimental' use.
They'd be ignored by any other mp3 player.

Yotam



On Fri, Oct 8, 2010 at 3:32 PM, Max Horn <max at quendi.de> wrote:
>
> Am 08.10.2010 um 15:00 schrieb yotam barnoy:
>
>> We also have to remember that even going by the 100 points that Xing
>> supplies, we won't have accurate precision time-wise, because it
>> doesn't store the time values but rather fraction of the file length
>> in 8 bit values.
>
> Ugh. You are right. To be honest, I missed that part in the XING header spec. That sounds pretty useless to me, actually... Maybe we should look at the VBRI header a bit closer then...
>
> And maybe we should contact the mplayer/ffmpeg/... folks and ask them whether they have recommendations for us.
>
> Note that ffmpeg has some code to parse Xing/Info/VBRI headers, see <http://ffmpeg.org/doxygen/0.6/mp3_8c.html#bfdff55d313b6aab5613899165fc0ce3>
>
>>
>> We'll have to test and see how good it is.
>
> Indeed...
>
>
> Bye,
> Max




More information about the Scummvm-devel mailing list