Ralph, thanks for your help.
>>Since the length of the precedent identification header is fixed, this
even is a fixed offset
>>into the logical ogg stream.
>This will work for all the vorbis-only files I've seen (because no one
>pads the first packet). You should really implement a proper ogg parser,
>but by all means get a hack working first.
I will of course use the ogg pages and their lacing values to exactly determine
where the packets start and end. It just wasn't clear to me that the lacing
values signal the borders of the packets in such a clean way (this actually
isn't very easy to read out from the specs for a person which is new to
ogg).
I thought padding of the first packet in an ogg stream is forbidden:
http://xiph.org/vorbis/doc/Vorbis_I_spec.html#vorbis-spec-codec says
"An
end-of-packet condition during decoding the first or third header
packet renders the stream undecodable."
Or does the end-of-packet condition only refers to packets which actually should
be greater than the lacing values indicate (in other words, truncated and
therefore corrupted packets, at least when speaking about the header packets)?
>The vorbis spec allows the comment packet to be up to
>18446744078004518921 bytes long. Of course it would be silly to
>use all of that, but if someone stuffs liner notes or cover art in
>there, it could easily be over the normal 4k page size.
Thanks, I already found out in the meantime that it must be this way, just
because the comment header can be so big (well, a 2^64 byte comment header
actually would be so big that it can't be stored on any currently existing
hardware anyway ;)
>Ouch. This is incorrect. It should read "It uses two additional header
>packets per logical bitstream."
I thought it must be this way.
>You have to know the codec embedding (or
>use a skeleton "meta-header" stream) to find the boundary between
the
>headers and the data, if any.
Yes, but in case of vorbis it's clear since I know that the first three
packets are the headers.
>Yow. Ralph, Silvia, should we consider creating an updated Ogg
>Internet-Draft and fixing / clarifying this and any other recent
>issues?
I would really appreciate that, at least for the vorbis comments. I think most
vorbis interested developers mainly care about the comments because of tagging
purposes.
The specs at http://xiph.org/vorbis/doc/v-comment.html are nice, but not
sufficient to actually implement an ogg vorbis comment reader / writer. There
should be a single document like it exists for the ID3 standard which completely
covers all relevant things to do when somebody wants to deal with vorbis
comments. There also should be an "official recommendation" that the
comment header is written with sufficient padding when a file has to be
rewritten anyway so that future tagging of that file can be done fastly.
As soon as I've finished implementing a working vorbis comments .NET library
(which I want to do until the end of March), I can offer to write such specs.
Maybe thats a good idea since I can write these specs from the "developer
without ogg knowledge view". You could (and should) check the specs for
correctitude afterwards, of course. Let me know if you're interested in.
Cheers
Mathias
___________________________________________________________
Der fr?he Vogel f?ngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail:
http://mail.yahoo.de