[Vorbis] metadata

[Ian Malone]

Ralph Giles wrote:
> On Sun, Oct 02, 2005 at 05:31:54PM +0100, Ian Malone wrote:
> 
> 
>>Okay, I've rigged up a simple test with the following four packets:

<snip>

>> Testing with XMMS I found it would refuse to play if the xml stream
>> header came first.
> 
> 
> Well, that's good news. I thought it might succeed in 'accidentally'
> working with vorbisfile in some cases.
> 
> The first xml page should definitely go after the vorbis bos. The
> rule of thumb is that the dominant media type goes first so file
> magic can identify the stream. So an Ogg Vorbis file, even with
> metadata, subtitles, etc, should start with the vorbis bos.

I hadn't thought about the file magic aspect.  It's roughly
equivalent to the following anyway:

> 
> Also, I think vorbisfile expects the first page it gets to be
> the vorbis stream.
> 

I thought as much given the Vorbis I specification and from looking
at the reference encoder.  Xine and MPlayer were the most competent
I tried; both appear to have demuxers, found and ignored the second
stream, and both succeeded when the XML stream came first (although
as you point out this isn't a good arrangement).  MPlayer does
slightly better in that it tells you it's ignoring a stream, Xine
has to be asked.  Neither is really a music player though.

> 
>>As an aside, while I was playing with libogg, I tried copying a file
>>packet-by-packet, the result passed through ogginfo gave:
>>"Negative granulepos on vorbis stream outside of headers. This file
>>was created by a buggy encoder."
> 
> 
> I expect what's happening is that when vorbisenc produces the initial 
> packet stream it sets a granulepos on every packet; libogg trusts these.
> But what you get from ogg_stream_packetout() only has the granulepos
> set on periodic packets, and this confuses the granulepos choice logic
> (or it just splits the packet stream at different points) in libogg,
> so you end up with *pages* marked with a granulepos of -1.
> 

Well this makes sense, thanks.  In the debugger I could see they were
coming out with granulepos -1. I thought there was a buffer overrun
somewhere in my code and was going mad.

> 
>>A summary of the players I've tried so far follows.
> 
> 
> Thanks for the summary. Too bad about helix. They have a real Ogg mux 
> though (and handle theora) so it should be straightforward to add the
> type and/or ignore unknown stream types.
> 

I seem to have the latest version.  I'll file a bug and see what
happens.  "Hi, I want to corrupt all my files, can you help?"
It's not clear to me what the type should be,
"<?xml version='1.0'?>" is clear enough to determine XML, but the
header should probably indicate the type of stream.  So we need
to go to the rdf tag, making the header for a qualified rdf stream:
<?xml version='1.0'?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
             xmlns:dc="http://purl.org/dc/elements/1.1/"
             xmlns:dcterms="http://purl.org/dc/terms/">

-- 
imalone