dev builds
themes manual
device status forums
mailing lists
IRC bugs
dev guide

Rockbox mail archive

Subject: Re: Ang: Re: Ang: Re: Vorbis metadata

Re: Ang: Re: Ang: Re: Vorbis metadata

From: Dave Chapman <>
Date: Mon, 20 Jun 2005 15:16:42 +0100 wrote:
>>The existing Ogg parser (in the same way as all the other parsers)
>>currently converts the sample count to a duration in ms before storing
>>it with the metadata about the file. So yes, unless that part of
>>Rockbox changes, the duration in ms is all that's needed.
>>But how do you calculate the length in ms without calculating the total
>>samples? Is that information stored somewhere in the Ogg headers?
> Well, I don't do much, vorbisfile.c does. :) It appears to be based on the
> granulepos, which is a part of each ogg page. And the problem with sample
> count was that I had to remove some calculations related to a field called
> pcm_offset, and I wasn't sure at the time what it was used for.

My (limited) understanding is that granulepos is basically just a
timestamp (of the last PCM sample in that packet), but measued in
samples, NOT ms. Ogg Vorbis streams start with a timestamp of 0, so
finding the timestamp (granulepos) of the last packet is enough to find
total samples.

If Tremor is using a pcm_offset variable, then it's possible that Ogg
Vorbis streams don't always start at zero - probably if they have been cut.

> I've looked at the memory usage a bit now, and it isn't great. To get full
> information (including length), it needs up to 120 kB or so, on the test
> files I've used (and that's excluding some alloca() stuff). A bit much for
> static allocation, though in the iRiver case, not too bad really. :)

I'm not surprised by that. The very simple Ogg parser currently in
Rockbox uses 255 bytes of an existing buffer - i.e. zero addition memory
usage beyond the code itself.

This doesn't include a vorbis comments parser, but that shouldn't need
much RAM either.

> Btw, I had a look at the existing Ogg parser, and I noticed it doesn't handled
> chained streams well. In those cases there are several end-of-stream pages
> in one file, and they should be accumulated for the total length.

I take full blame for that. Patches welcome :-).

I tried to understand the Ogg specifications on the Xiph website, but
couldn't. So I am sure there is a lot of room for improvement.

All I think that's needed is for someone to understand the basic
structure of an Ogg Vorbis file, and then write a very simple, very
minimal parser for it.

Received on 2005-06-20

Page was last modified "Sat May 23 08:12:40 2020" The Rockbox Crew