From R.S.Bultje at students.uu.nl  Mon Mar  1 00:12:07 2004
From: R.S.Bultje at students.uu.nl (Ronald S. Bultje)
Date: Mon, 01 Mar 2004 00:12:07 +0100
Subject: [Matroska-devel] ffmpeg
Message-ID: <1078096327.2303.10.camel@shrek.bitfreak.net>

Hi all,

Me and Mosu worked on this some time ago, we didn't finish it due to a
lack of time (my move to the US, his exams). I gave it some more time
today and got it to basically work. I can now watch matroska movies
using ffmpeg.

So... The attached patch adds matroska support to ffmpeg. Please review,
tests, comment, etc. I'll send it to the ffmpeg people when we've
reviewed it and all's well.

Thanks to Mosu for doing part of the job of porting the GStreamer plugin
to ffmpeg.

Ronald
-------------- next part --------------
A non-text attachment was scrubbed...
Name: matroska.diff
Type: text/x-patch
Size: 122636 bytes
Desc: not available
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20040301/c7cab9d5/attachment.bin>

From moritz at bunkus.org  Tue Mar  2 09:50:47 2004
From: moritz at bunkus.org (Moritz Bunkus)
Date: Tue, 2 Mar 2004 09:50:47 +0100
Subject: [Matroska-devel] ffmpeg
In-Reply-To: <1078096327.2303.10.camel@shrek.bitfreak.net>
References: <1078096327.2303.10.camel@shrek.bitfreak.net>
Message-ID: <20040302085047.GU6917@bunkus.org>

Heya Ronald,

I'm sorry I haven't commented so far, but I'm really busy these days. I
hope I can test this tonight.

One thing that you've probably noticed yourself by now is that you
should diff against the original libavformat's Makefile, not against
your autoconf'ed version.

Mosu

-- 
If Darl McBride was in charge, he'd probably make marriage
unconstitutional too, since clearly it de-emphasizes the commercial
nature of normal human interaction, and probably is a major impediment
to the commercial growth of prostitution. - Linus Torvalds


From rbultje at ronald.bitfreak.net  Tue Mar  2 15:58:47 2004
From: rbultje at ronald.bitfreak.net (Ronald Bultje)
Date: Tue, 2 Mar 2004 15:58:47 +0100 (CET)
Subject: [Matroska-devel] ffmpeg
In-Reply-To: <20040302085047.GU6917@bunkus.org>
Message-ID: <Pine.LNX.4.33.0403021558030.13422-100000@raq.textinfo.nl>

Hi Moritz,

On Tue, 2 Mar 2004, Moritz Bunkus wrote:
> One thing that you've probably noticed yourself by now is that you
> should diff against the original libavformat's Makefile, not against
> your autoconf'ed version.

I did. This patch is queued first in my patchset for ffmpeg. The autotools
patch comes next.

Ronald



From jcsston at wiesneronline.net  Sat Mar  6 08:47:49 2004
From: jcsston at wiesneronline.net (Jory)
Date: Sat, 6 Mar 2004 01:47:49 -0600
Subject: [Matroska-devel] Incomplete Matroska File, crashes libebml
References: <000801c3f78c$69882cc0$0200a8c0@jcsston>
	<000601c3fb4e$85da8f60$0200a8c0@jcsston>
Message-ID: <000601c4034f$612b64b0$0200a8c0@jcsston>

Fix commited to libebml CVS

The bug was the ebml size reading code was overrunning the buffer it had for
data sizes, it's limited to 8 bytes but never checked if it was going over.
A simple if (size >=8) return NULL; fixed it.

Later,
Jory

----- Original Message -----
From: "Jory" <jcsston at wiesneronline.net>
To: "Jory" <jcsston at wiesneronline.net>
Sent: Tuesday, February 24, 2004 9:21 PM
Subject: Re: [Matroska-devel] Incomplete Matroska File, crashes libebml


> A small update,
> alexnoe has fixed AVIMux-GUI to not crash on this file.
>
> ----- Original Message -----
> From: "Jory" <jcsston at wiesneronline.net>
> To: <matroska-devel at lists.matroska.org>
> Sent: Friday, February 20, 2004 2:34 AM
> Subject: [Matroska-devel] Incomplete Matroska File, crashes libebml
>
>
> > I have an incomplete Matroska file that libebml crashes on when trying
to
> > read the ebml header.
> >
> > I uploaded it to
> > http://www.mycgiserver.com/~jcsston/simp.avi.mkv.zip
> > Do not extract this with the Shell Ext installed
> >
> > I did a little debugging and it looks like it is stuck in a loop in
> > EbmlElement.cpp:266 - 270.
> >
> > Jory
> >
> > _______________________________________________
> > Matroska-devel mailing list
> > Matroska-devel at lists.matroska.org
> > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel



From chris at matroska.org  Sat Mar  6 12:23:39 2004
From: chris at matroska.org (Christian HJ Wiesner)
Date: Sat, 06 Mar 2004 12:23:39 +0100
Subject: [Matroska-devel] Incomplete Matroska File, crashes libebml
In-Reply-To: <000601c4034f$612b64b0$0200a8c0@jcsston>
References: <000801c3f78c$69882cc0$0200a8c0@jcsston>	<000601c3fb4e$85da8f60$0200a8c0@jcsston>
	<000601c4034f$612b64b0$0200a8c0@jcsston>
Message-ID: <4049B4BB.1040801@matroska.org>

Jory wrote:

>Fix commited to libebml CVS
>
>The bug was the ebml size reading code was overrunning the buffer it had for
>data sizes, it's limited to 8 bytes but never checked if it was going over.
>A simple if (size >=8) return NULL; fixed it.
>Later,
>Jory
>  
>
:-) ...... hey robux4, jcsston will soon be announced as the official
'matroska lead developer' if you dont try to catch up with him soon :D
...... lol ....

Christian





From steve.lhomme at free.fr  Sun Mar  7 17:30:51 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Sun, 07 Mar 2004 17:30:51 +0100
Subject: [Matroska-devel] [Fwd: AW: WAV MPEG Header]
Message-ID: <404B4E3B.7050303@free.fr>

Anyone has info on this ?

-------- Original Message --------
Subject: AW: WAV MPEG Header
Date: Sun, 7 Mar 2004 17:06:09 +0100
From: Mark Essien <mark at essien.de>
Organization: Essien Research & Development
To: 'Steve Lhomme' <steve.lhomme at free.fr>

Hi Steve :)

Thanks for the info. Yes, I need that info a lot. You see, I made this MPEG
encoder that multiplexes a PCM and an MPEG-video stream, however, no player
I can find can play the PCM stream. And it stands to reason, because there
are various sample rates that can be used for a PCM stream, and the player
has to find that out somehow or the other. I tried writing a RIFF header,
but that did not help either. I'm quite puzzled about this, and even the
all-knowing google could not help much :)

It would be nice if you could direct me to someone who could tell me this,
yes, and thanks a lot!

Regards,
Mark.
---------
Essien Research & Development
10243 Berlin, Germany.
+49 3041727690
http://www.essien.de

-----Urspr?ngliche Nachricht-----
Von: Steve Lhomme [mailto:steve.lhomme at free.fr]
Gesendet: Sonntag, 7. M?rz 2004 11:28
An: Mark Essien
Betreff: Re: WAV MPEG Header

Mark Essien wrote:
> Hello,
> 
> I see that you are quite the pro in this area - when an MPEG stream 
> uses uncompressed PCM audio as the audio track, does it have to 
> contain the WAV header? For example, in DVDs.

I'm not really a pro for MPEG streams. But it's very unlikely that it uses
the WAV (RIFF) header for PCM data. But I don't know how the format is
recognised in interleaved MPEG streams... If you need these info I can
redirect you to the right people :)

cya








From spyder at matroska.org  Mon Mar  8 01:30:51 2004
From: spyder at matroska.org (John Cannon)
Date: Sun, 07 Mar 2004 18:30:51 -0600
Subject: [Matroska-devel] [Fwd: AW: WAV MPEG Header]
In-Reply-To: <404B4E3B.7050303@free.fr>
References: <404B4E3B.7050303@free.fr>
Message-ID: <404BBEBB.8020601@matroska.org>

Steve Lhomme wrote:

> Anyone has info on this ?
>
> -------- Original Message --------
> Subject: AW: WAV MPEG Header
> Date: Sun, 7 Mar 2004 17:06:09 +0100
> From: Mark Essien <mark at essien.de>
> Organization: Essien Research & Development
> To: 'Steve Lhomme' <steve.lhomme at free.fr>
>
> Hi Steve :)
>
> Thanks for the info. Yes, I need that info a lot. You see, I made this 
> MPEG
> encoder that multiplexes a PCM and an MPEG-video stream, however, no 
> player
> I can find can play the PCM stream. And it stands to reason, because 
> there
> are various sample rates that can be used for a PCM stream, and the 
> player
> has to find that out somehow or the other. I tried writing a RIFF header,
> but that did not help either. I'm quite puzzled about this, and even the
> all-knowing google could not help much :)
>
> It would be nice if you could direct me to someone who could tell me 
> this,
> yes, and thanks a lot!
>
> Regards,
> Mark.
> ---------
> Essien Research & Development
> 10243 Berlin, Germany.
> +49 3041727690
> http://www.essien.de
>
> -----Urspr?ngliche Nachricht-----
> Von: Steve Lhomme [mailto:steve.lhomme at free.fr]
> Gesendet: Sonntag, 7. M?rz 2004 11:28
> An: Mark Essien
> Betreff: Re: WAV MPEG Header
>
> Mark Essien wrote:
>
>> Hello,
>>
>> I see that you are quite the pro in this area - when an MPEG stream 
>> uses uncompressed PCM audio as the audio track, does it have to 
>> contain the WAV header? For example, in DVDs.
>
>
> I'm not really a pro for MPEG streams. But it's very unlikely that it 
> uses
> the WAV (RIFF) header for PCM data. But I don't know how the format is
> recognised in interleaved MPEG streams... If you need these info I can
> redirect you to the right people :)
>
> cya
>
>
>
>
>
>
> _______________________________________________
> Matroska-devel mailing list
> Matroska-devel at lists.matroska.org
> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
>
>
I'm quite positive it doesn't use a RIFF header.  I really don't know 
what it uses though.  I assume you are talking about Linear PCM.  You 
could look in the dvd2avi sources to figure out how it detects the 
samplerate etc..  I don't think the regulare MPEG spec defines this but 
I could be wrong.

Spyder


From steve.lhomme at free.fr  Mon Mar  8 10:51:47 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Mon, 08 Mar 2004 10:51:47 +0100
Subject: [Matroska-devel] Subversion is good for you
Message-ID: <404C4233.6030908@free.fr>

http://osdir.com/Article203.phtml

BTW any news on a CoreCodec update ?


From paul at msn.com  Wed Mar 10 07:58:23 2004
From: paul at msn.com (Paul Bryson)
Date: Wed, 10 Mar 2004 00:58:23 -0600
Subject: [Matroska-devel] Formatting the Matroska specs
Message-ID: <c2mea9$q04$1@sea.gmane.org>

I've been pretty busy lately but I would really like to format the Matroska
specs in the way that was mentioned earlier on the list that would store all
specs in one page, but use something to hide elements for a version that you
don't want to see.  I'm pretty sure this can be done fine using CSS classes as
done here.
http://www.jkfanclub.com:81/spec-test.html
I just need to add a class="" to each element in the specs and label it with the
minimum required element.  I was convinced of the virtues of CSS when I first
saw
http://www.csszengarden.com/

However, we would still need a simple method for determining which style sheet
should be used.  Perhaps something like this? (very bottom)
http://scdc.sccs.swarthmore.edu/

Are there any opinions on if any of this would be good or not?


Paul





From moritz at bunkus.org  Wed Mar 10 10:32:20 2004
From: moritz at bunkus.org (Moritz Bunkus)
Date: Wed, 10 Mar 2004 10:32:20 +0100
Subject: [Matroska-devel] Formatting the Matroska specs
In-Reply-To: <c2mea9$q04$1@sea.gmane.org>
References: <c2mea9$q04$1@sea.gmane.org>
Message-ID: <20040310093220.GB6176@bunkus.org>

Heya,

I like CSS, and Opera seems to like them as well. At least the Zen
garden looks very nice in it. 

> http://www.jkfanclub.com:81/spec-test.html

Can't connect, so I'll test later.

My thoughts are that having the specs on separate pages has its
advantages, too: e.g. the explanations for the chapters don't really fit
into the other page. If anything I'd say that the main big specs page
should be split further into separate pages. The stuff at the bottom
(player profiles etc) could very well be put onto another page.

On the other hand: If you manage to create an easily accessible document
with CSS then that might be good as well. So why don't you try it? :)

Mosu

-- 
If Darl McBride was in charge, he'd probably make marriage
unconstitutional too, since clearly it de-emphasizes the commercial
nature of normal human interaction, and probably is a major impediment
to the commercial growth of prostitution. - Linus Torvalds


From steve.lhomme at free.fr  Wed Mar 10 21:01:12 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Wed, 10 Mar 2004 21:01:12 +0100
Subject: [Matroska-devel] Formatting the Matroska specs
In-Reply-To: <20040310093220.GB6176@bunkus.org>
References: <c2mea9$q04$1@sea.gmane.org> <20040310093220.GB6176@bunkus.org>
Message-ID: <404F7408.2070805@free.fr>

Moritz Bunkus wrote:
> Heya,
> 
> I like CSS, and Opera seems to like them as well. At least the Zen
> garden looks very nice in it. 
> 
> 
>>http://www.jkfanclub.com:81/spec-test.html
> 
> 
> Can't connect, so I'll test later.
> 
> My thoughts are that having the specs on separate pages has its
> advantages, too: e.g. the explanations for the chapters don't really fit
> into the other page. If anything I'd say that the main big specs page
> should be split further into separate pages. The stuff at the bottom
> (player profiles etc) could very well be put onto another page.

I agree on putting the profiles elsewhere. Especially since they are not 
up to date...
Also one day we should try to make a DocBook out of the specs. With a 
more detailed descriptions for each elements (like a real spec).




From alexander.noe at s2001.tu-chemnitz.de  Wed Mar 10 21:06:09 2004
From: alexander.noe at s2001.tu-chemnitz.de (=?ISO-8859-1?Q?Alexander_No=E9?=)
Date: Wed, 10 Mar 2004 21:06:09 +0100
Subject: [Matroska-devel] Formatting the Matroska specs
In-Reply-To: <404F7408.2070805@free.fr>
References: <c2mea9$q04$1@sea.gmane.org> <20040310093220.GB6176@bunkus.org>
	<404F7408.2070805@free.fr>
Message-ID: <404F7531.5030707@hrz.tu-chemnitz.de>

Steve Lhomme wrote:

> I agree on putting the profiles elsewhere. Especially since they are 
> not up to date...
> Also one day we should try to make a DocBook out of the specs. With a 
> more detailed descriptions for each elements (like a real spec).

Actually, I intended to start that not long ago.

Should that be written in english or in specification-english?




Alex




From steve.lhomme at free.fr  Wed Mar 10 21:16:57 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Wed, 10 Mar 2004 21:16:57 +0100
Subject: [Matroska-devel] Formatting the Matroska specs
In-Reply-To: <404F7531.5030707@hrz.tu-chemnitz.de>
References: <c2mea9$q04$1@sea.gmane.org>
	<20040310093220.GB6176@bunkus.org>	<404F7408.2070805@free.fr>
	<404F7531.5030707@hrz.tu-chemnitz.de>
Message-ID: <404F77B9.9000404@free.fr>

Alexander No? wrote:

> Steve Lhomme wrote:
> 
>> I agree on putting the profiles elsewhere. Especially since they are 
>> not up to date...
>> Also one day we should try to make a DocBook out of the specs. With a 
>> more detailed descriptions for each elements (like a real spec).
> 
> 
> Actually, I intended to start that not long ago.
> 
> Should that be written in english or in specification-english?

What is the difference ?




From alexander.noe at s2001.tu-chemnitz.de  Wed Mar 10 21:23:51 2004
From: alexander.noe at s2001.tu-chemnitz.de (=?ISO-8859-1?Q?Alexander_No=E9?=)
Date: Wed, 10 Mar 2004 21:23:51 +0100
Subject: [Matroska-devel] Formatting the Matroska specs
In-Reply-To: <404F77B9.9000404@free.fr>
References: <c2mea9$q04$1@sea.gmane.org>	<20040310093220.GB6176@bunkus.org>	<404F7408.2070805@free.fr>	<404F7531.5030707@hrz.tu-chemnitz.de>
	<404F77B9.9000404@free.fr>
Message-ID: <404F7957.1060305@hrz.tu-chemnitz.de>

Steve Lhomme wrote:

> Alexander No? wrote:
>
>> Actually, I intended to start that not long ago.
>>
>> Should that be written in english or in specification-english?
>
>
> What is the difference ?

real english: "This value must not be zero"
specification english (same meaning!): "This value shall not be zero".




Alex




From steve.lhomme at free.fr  Wed Mar 10 21:32:41 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Wed, 10 Mar 2004 21:32:41 +0100
Subject: [Matroska-devel] Formatting the Matroska specs
In-Reply-To: <404F7957.1060305@hrz.tu-chemnitz.de>
References: <c2mea9$q04$1@sea.gmane.org>	<20040310093220.GB6176@bunkus.org>	<404F7408.2070805@free.fr>	<404F7531.5030707@hrz.tu-chemnitz.de>	<404F77B9.9000404@free.fr>
	<404F7957.1060305@hrz.tu-chemnitz.de>
Message-ID: <404F7B69.7000305@free.fr>

Alexander No? wrote:

> Steve Lhomme wrote:
> 
>> Alexander No? wrote:
>>
>>> Actually, I intended to start that not long ago.
>>>
>>> Should that be written in english or in specification-english?
>>
>>
>>
>> What is the difference ?
> 
> 
> real english: "This value must not be zero"
> specification english (same meaning!): "This value shall not be zero".

I prefer the latter.




From matroska at mani.user.lysator.liu.se  Wed Mar 10 22:03:03 2004
From: matroska at mani.user.lysator.liu.se (Martin Nilsson)
Date: Wed, 10 Mar 2004 22:03:03 +0100
Subject: [Matroska-devel] Formatting the Matroska specs
In-Reply-To: <404F7957.1060305@hrz.tu-chemnitz.de>
References: <c2mea9$q04$1@sea.gmane.org> <20040310093220.GB6176@bunkus.org>
	<404F7408.2070805@free.fr> <404F7531.5030707@hrz.tu-chemnitz.de>
	<404F77B9.9000404@free.fr> <404F7957.1060305@hrz.tu-chemnitz.de>
Message-ID: <404F8287.7000407@mani.user.lysator.liu.se>

Alexander No? wrote:

> Steve Lhomme wrote:
>  
> real english: "This value must not be zero"
> specification english (same meaning!): "This value shall not be zero".

RFC english: "This value SHALL NOT be zero".

/Martin Nilsson



From matroska at mani.user.lysator.liu.se  Wed Mar 10 22:17:10 2004
From: matroska at mani.user.lysator.liu.se (Martin Nilsson)
Date: Wed, 10 Mar 2004 22:17:10 +0100
Subject: [Matroska-devel] EBML
Message-ID: <404F85D6.2080701@mani.user.lysator.liu.se>


I'm sorry to dragged this out, but I've had a few other things to attend 
to. The functionally complete EBML draft is ready for scrutiny. It 
turned out a bit bigger than I first anticipated, but that's life...
http://www.lysator.liu.se/~mani/ebml/ebml-1.0.txt

/Martin Nilsson.



From nilsson at pike.ida.liu.se  Wed Mar 10 22:30:13 2004
From: nilsson at pike.ida.liu.se (Martin Nilsson)
Date: Wed, 10 Mar 2004 22:30:13 +0100
Subject: [Matroska-devel] Re: Re: EBML (subitles)
In-Reply-To: <403356B8.2060608@matroska.org>
References: <402BAA2A.6060008@mani.user.lysator.liu.se>
	<402BE1B6.5050105@free.fr>
	<402C21FC.6070206@mani.user.lysator.liu.se>
	<c0hue9$93q$1@sea.gmane.org>
	<4031B42B.2070509@mani.user.lysator.liu.se>
	<c0v1ib$r2n$1@sea.gmane.org>
	<40332029.2010806@mani.user.lysator.liu.se>
	<403356B8.2060608@matroska.org>
Message-ID: <404F88E5.8020604@pike.ida.liu.se>

unmei wrote:

> i'm currently developing a new graphical subtitle format. It's in the 
> early implementation and still change phase but it shows good results so 
> far. I hope it will allow to compress full color subtitles at about the 
> size of (4 color) sub/idx. I think 1 mb per stream (language) is 
> possible and maybe even 400 or less kb could be attained. I designed it 
> to be not CPU demanding by not incoprorating sophisticated compression 
> schemes (_not_ like png, lzw et all) but my current encoder is extremely 
> slow (probably because i re-resize the target array quite often and 
> hopefully more avoidable stupidities).

As I've already mentioned I don't think that the "sophisticated 
compression schemes" you mention is a problem. It is usually quite cheap 
to decompress them. It is often the predictors that are time consuming. 
To counter a measurement made in another post, I tried to see how much 
PNG data I could decode while playing an ordinary TV-rip avi. On a 1GHz 
PIII I could decode 20 1000x1000 pixels PNG images per second without 
losing framerate in The West Wing. And subtitles rarely change once 
every frame nor is 1000x1000 pixels. I didn't use libpng though.... Note 
that alpha blending isn't a concern since all modern graphics cards can 
do it in hardware.

Do take in consideration that for many applications it is beneficial to 
have the textual data alongside the rendered data, to. e.g. facilitate 
text search.

/Martin Nilsson



From matroska at mani.user.lysator.liu.se  Wed Mar 10 22:45:10 2004
From: matroska at mani.user.lysator.liu.se (Martin Nilsson)
Date: Wed, 10 Mar 2004 22:45:10 +0100
Subject: [Matroska-devel] Gstreamer and matroska - the opensource answer
	to VideoforWindows/AVI and Quicktime/MOV ?
In-Reply-To: <40338455.3050905@matroska.org>
References: <40338455.3050905@matroska.org>
Message-ID: <404F8C66.9050202@mani.user.lysator.liu.se>

Christian HJ Wiesner wrote:
> DivX.com have plans to release DivX6 from AVI and VCM, as well as from 
> the MPEG4 standard in general. They have plans for a new, DivX6 specific 
> container format i heard, and want to establish themselves as a new 
> video standard that way, even with hardware support.

Yes, and they do not consider Matroska because Matroska and their DivX6 
container have conflicting goals. DivX Networks wants to have a format 
that can be _fully_ supported, so when you build a box and put a DivX6 
sticker on it you can promise the customer that it can play all possible 
codec combinations ever available for DivX6.

This is of course nothing more than a marketing strategy to gently fool 
the customer, because when technology has evolved they will release the 
DivX7 container with another set of fixed codecs. It is however 
important to have a frozen, well defined specification to launch big 
volume consumer products.

Matroska profiles are too weak. To be a viable alternative Matroska must 
clearly seperate between the _framework_ Matroska, which may be as 
generalized as you wish, and the specific Matroska 2004 (or whatever) 
that only allows for a very specific set of options (possibly enforced 
by technical means). When I hinted in this direction earlier I didn't 
get the feeling that this is something anyone here is willing to do.

/Martin Nilsson



From paul at msn.com  Thu Mar 11 01:39:12 2004
From: paul at msn.com (Paul Bryson)
Date: Wed, 10 Mar 2004 18:39:12 -0600
Subject: [Matroska-devel] Re: Formatting the Matroska specs
References: <c2mea9$q04$1@sea.gmane.org> <20040310093220.GB6176@bunkus.org>
Message-ID: <c2ocf9$q5f$1@sea.gmane.org>

"Moritz Bunkus" wrote...
> > http://www.jkfanclub.com:81/spec-test.html
>
> Can't connect, so I'll test later.

I'm sorry, right after I posted this message, I rebooted my PC to run memtest on
it for the next 15 hours.  Sometimes I don't really thing out my plans,
especially at 2am.  It should be accessible now.  Well, I'm about to reboot my
PC to move around the ram again, but that will be 5 minutes max.


Pamel





From paul at msn.com  Thu Mar 11 16:10:39 2004
From: paul at msn.com (Paul Bryson)
Date: Thu, 11 Mar 2004 09:10:39 -0600
Subject: [Matroska-devel] Re: Formatting the Matroska specs
References: <c2mea9$q04$1@sea.gmane.org> <20040310093220.GB6176@bunkus.org>
Message-ID: <c2pvh5$bo5$1@sea.gmane.org>

"Moritz Bunkus" wrote...
> My thoughts are that having the specs on separate pages has its
> advantages, too: e.g. the explanations for the chapters don't really fit
> into the other page. If anything I'd say that the main big specs page
> should be split further into separate pages. The stuff at the bottom
> (player profiles etc) could very well be put onto another page.

Sorry, now that you can see the page I made, it should be more clear what I
meant.  I guess we could break down the specs page a little more.  But, my
intention was to have a single page that would let you see all of the elements,
just 1.0 elements, or any combination of versions.  That way we wouldn't have to
maintain two versions, one for 1.0, and the other for 2.0.


Pamel





From paul at msn.com  Thu Mar 11 23:45:08 2004
From: paul at msn.com (Paul Bryson)
Date: Thu, 11 Mar 2004 16:45:08 -0600
Subject: [Matroska-devel] Re: Formatting the Matroska specs
References: <c2mea9$q04$1@sea.gmane.org>
Message-ID: <c2qq57$g8p$1@sea.gmane.org>

I just updated the specs so that every element and section has a class of either
"version1" or "version2".  To show what can be done with this I have two
examples.

http://www.jkfanclub.com:81/matroska/Projects/specrevisions/version1/spectest.html
http://www.jkfanclub.com:81/matroska/Projects/specrevisions/version2/spectest.html

Both of these files are identical, but the CSS file they are using is different,
causing only the Version1 stuff to show up in the first page, and only the
Version2 stuff to show up in the second.  Its still a bit rough at the moment,
but I was wondering if everyone was okay with this.


Pamel





From paul at msn.com  Sat Mar 13 09:51:40 2004
From: paul at msn.com (Paul Bryson)
Date: Sat, 13 Mar 2004 02:51:40 -0600
Subject: [Matroska-devel] Duplicate element IDs
Message-ID: <c2ui2c$dgi$1@sea.gmane.org>

Haali recently pointed out to me that the element ID for the SignedElement and
CodecID elements are both [86].  I don't believe that anyone is using
SignedElement yet, so I went ahead and changed the ID to [65][32].  If anyone is
reading this element, please update your parsers.


Pamel





From paul at msn.com  Sat Mar 13 10:10:17 2004
From: paul at msn.com (Paul Bryson)
Date: Sat, 13 Mar 2004 03:10:17 -0600
Subject: [Matroska-devel] Re: Formatting the Matroska specs
References: <c2mea9$q04$1@sea.gmane.org> <c2qq57$g8p$1@sea.gmane.org>
Message-ID: <c2uj58$fbq$1@sea.gmane.org>

"Paul Bryson" wrote...
> I just updated the specs so that every element and section has a class of
either
> "version1" or "version2".  To show what can be done with this I have two
> examples.

I just made a new test page that I will use on the actual specs if no one has
any issues with it.  The page is viewable here:
http://www.jkfanclub.com:81/matroska/Projects/specrevisions/csschanger/spectest.html

It uses a very little bit of javascript with the listbox selection.  And if
javascript is disabled, decent browsers will let you select the style by hand.
Although, perhaps the javascript should be moved outside of the main specs page
into its own .js.  That way any changes to the javascript wouldn't require a
commit to the specs.

Comments, ideas?


Pamel





From paul at msn.com  Sat Mar 13 10:30:24 2004
From: paul at msn.com (Paul Bryson)
Date: Sat, 13 Mar 2004 03:30:24 -0600
Subject: [Matroska-devel] Re: EBML
References: <404F85D6.2080701@mani.user.lysator.liu.se>
Message-ID: <c2ukb0$ha1$1@sea.gmane.org>

"Martin Nilsson" wrote...
> I'm sorry to dragged this out, but I've had a few other things to attend
> to. The functionally complete EBML draft is ready for scrutiny. It
> turned out a bit bigger than I first anticipated, but that's life...
> http://www.lysator.liu.se/~mani/ebml/ebml-1.0.txt

I really wish I had time to actually read the whole thing now, but I might be
able to soon.  It is very impressive what you have done with this, much more
than any of the rest of us is capable, I think.

A few quick questions, I had always thought that the CRC32 and Void elements
were Matroska specific.  Is this the case, or are they in fact a part of the
EBML spec?

For "Appendix D.  Matroska DTD", the Chapters and Tags can each be nested
several layers deep within each other.  Is there any clean way to indicate this,
or am I missing it?

Is it necessary to define things such as how exactly a "Signed EBML Integer"
works?

And only slightly related to this, is the EBML project ever going to be moved to
Corecodec.org, or is it going to stay on SourceForge?


Pamel





From moritz at bunkus.org  Sat Mar 13 11:13:02 2004
From: moritz at bunkus.org (Moritz Bunkus)
Date: Sat, 13 Mar 2004 11:13:02 +0100
Subject: [Matroska-devel] Re: Formatting the Matroska specs
In-Reply-To: <c2uj58$fbq$1@sea.gmane.org>
References: <c2mea9$q04$1@sea.gmane.org> <c2qq57$g8p$1@sea.gmane.org>
	<c2uj58$fbq$1@sea.gmane.org>
Message-ID: <20040313101302.GF6938@bunkus.org>

Heya,

> I just made a new test page that I will use on the actual specs if no one has
> any issues with it.  The page is viewable here:
> http://www.jkfanclub.com:81/matroska/Projects/specrevisions/csschanger/spectest.html

I like it, and it works well in Opera.

I agree that the javascript part should be a separate file. That makes
tracking changes to the specs a bit easier.

Mosu

-- 
If Darl McBride was in charge, he'd probably make marriage
unconstitutional too, since clearly it de-emphasizes the commercial
nature of normal human interaction, and probably is a major impediment
to the commercial growth of prostitution. - Linus Torvalds


From moritz at bunkus.org  Sat Mar 13 11:16:01 2004
From: moritz at bunkus.org (Moritz Bunkus)
Date: Sat, 13 Mar 2004 11:16:01 +0100
Subject: [Matroska-devel] Duplicate element IDs
In-Reply-To: <c2ui2c$dgi$1@sea.gmane.org>
References: <c2ui2c$dgi$1@sea.gmane.org>
Message-ID: <20040313101601.GG6938@bunkus.org>

Hi,

I'm pretty sure noone uses those so far, so the change should be safe.
A quick 'grep' over the libmatroska sources shows that the ID you
proposed is not used elsewhere.

Mosu

-- 
If Darl McBride was in charge, he'd probably make marriage
unconstitutional too, since clearly it de-emphasizes the commercial
nature of normal human interaction, and probably is a major impediment
to the commercial growth of prostitution. - Linus Torvalds


From agebosma at home.nl  Sat Mar 13 16:41:49 2004
From: agebosma at home.nl (Age Bosma)
Date: Sat, 13 Mar 2004 16:41:49 +0100
Subject: [Matroska-devel] Tag names
Message-ID: <40532BBD.8060909@home.nl>

Hi,

I'm working on a general reference table for tag/field names of the 
different tag types used (OGG, ID3, APE, Matroska) and I got pointed to 
the list your are providing on the matroska website.
I decided to use your table as a base and add the other tag type names 
to it because your list nicely sorted into groups.

First of all your page is containing one dead link and one typo:
http://matroska.org/technical/specs/tagging/index.html
The Example XML Tags link 
(http://matroska.org/technical/specs/tagging/tagexamples/example.xml) is 
dead at the moment.
The tag INTERNET_RADIO_STATION is akin to the TRSN tag in ID3v2.4 
instead of the TSRN tag. This one doesn't exist ;-)

Is there any list available which already contains more comparison 
information including other tag types? If not I'm going to extend my 
list and if you like I'll keep you informed about updates incase you 
might want to use it as well.
Am I correct the current Matroska list doesn't include all id3 
comparisons yet? There seem to be some more similarities which aren't 
included yet. Or has the list already been completed and you've desided 
that there are no similarities close enough anymore?

Also, foobar is adding ReplayGain info using the REPLAYGAIN_TRACK_GAIN 
and REPLAYGAIN_TRACK_PEAK instead of the Matroska proposed 
REPLAYGAIN_GAIN and REPLAYGAIN_PEAK. The first two names seem to 
describe the information better imo. Especially compared to the names 
used for the album gain and peak in Matroska. Also if sticking to the 
first two names it would be more consistent with the other formats.

I would love to see the XML Example because this is the reason why I 
started creating the reference file in the first place. I want to 
develop a general xml output format to export e.g. playlist information 
in time this could be used as a playlist format as well.
Is there discussion taking place somewhere about this subject? I would 
like to contribute because there's no point in inventing the wheel twice.

This is what I got so far, not including Matroska yet: 
http://hobba.hobba.nl/audio/tagfields.html
While adding Matroska to the list I already came across some minor 
errors which are being corrected as we speak.

Cheers,

Age


From paul at msn.com  Sat Mar 13 19:51:08 2004
From: paul at msn.com (Paul Bryson)
Date: Sat, 13 Mar 2004 12:51:08 -0600
Subject: [Matroska-devel] Re: Tag names
References: <40532BBD.8060909@home.nl>
Message-ID: <c2vl69$l03$1@sea.gmane.org>

"Age Bosma" wrote...
> I'm working on a general reference table for tag/field names of the
> different tag types used (OGG, ID3, APE, Matroska)

I actually made one of these around a year ago, but it is incomplete, and not
updated for Matroska.

> First of all your page is containing one dead link and one typo:
> http://matroska.org/technical/specs/tagging/index.html
> The Example XML Tags link
> (http://matroska.org/technical/specs/tagging/tagexamples/example.xml) is
> dead at the moment.

Sorry, it looks like the server config has been changed to not auto copy *.xml
files out of CVS to the web server.  I'll ask about getting this fixed.  In the
mean time, here is a link to the example it CVS.
http://cvs.corecodec.org/cgi-bin/viewcvs.cgi/*checkout*/matroska/doc/website/technical/specs/tagging/tagexamples/example.xml

> The tag INTERNET_RADIO_STATION is akin to the TRSN tag in ID3v2.4
> instead of the TSRN tag. This one doesn't exist ;-)

I swear I have fixed this before, but I'm not sure what happenned to it.  Fixed
now...again...whatever.

> Is there any list available which already contains more comparison
> information including other tag types? If not I'm going to extend my
> list and if you like I'll keep you informed about updates incase you
> might want to use it as well.

Take a look at this post.
http://thread.gmane.org/gmane.comp.multimedia.matroska.devel/536
Also look at the files here:
http://www.jkfanclub.com:81/matroska/Projects/
Particularly:
http://www.jkfanclub.com:81/matroska/Projects/matroskatags5.xls

The Matroska Tags listed in that excel spreadsheet are from the old system and
no longer apply.  But, it is a good reference for other tags.

I would definately be interested in any updates that you could make to that.

> Am I correct the current Matroska list doesn't include all id3
> comparisons yet? There seem to be some more similarities which aren't
> included yet. Or has the list already been completed and you've desided
> that there are no similarities close enough anymore?

As you can see, it used to.  However, with the simplification process that took
place with the tags, there is no longer a one-to-one mapping of tags.  Many of
the ID3 tags would be mapped to nested tags inside of Matroska.  For instance:
wwwartist
would be mapped to a URL tag underneath the LEAD_PERFORMER tag.  This specific
example is even viewable in the example.xml.

> Also, foobar is adding ReplayGain info using the REPLAYGAIN_TRACK_GAIN
> and REPLAYGAIN_TRACK_PEAK instead of the Matroska proposed
> REPLAYGAIN_GAIN and REPLAYGAIN_PEAK. The first two names seem to
> describe the information better imo. Especially compared to the names
> used for the album gain and peak in Matroska. Also if sticking to the
> first two names it would be more consistent with the other formats.

Ugh.  I misread what Peter wrote to me earlier.  This has been changed now,
although I'm not sure if it makes any sense in the context of movies.  However,
given that he has the only implementation of this, I'll change it.

> This is what I got so far, not including Matroska yet:
> http://hobba.hobba.nl/audio/tagfields.html

Looks good.

> While adding Matroska to the list I already came across some minor
> errors which are being corrected as we speak.

For quick questions, irc is probably the best method for a quick response.
irc://irc.corecodec.com:6667/matroska


Pamel





From agebosma at home.nl  Sun Mar 14 20:25:04 2004
From: agebosma at home.nl (Age Bosma)
Date: Sun, 14 Mar 2004 20:25:04 +0100
Subject: [Matroska-devel] Re: Tag names
In-Reply-To: <c2vl69$l03$1@sea.gmane.org>
References: <40532BBD.8060909@home.nl> <c2vl69$l03$1@sea.gmane.org>
Message-ID: <4054B190.7050008@home.nl>

Paul Bryson wrote:
> 
>>The tag INTERNET_RADIO_STATION is akin to the TRSN tag in ID3v2.4
>>instead of the TSRN tag. This one doesn't exist ;-)
> 
> 
> I swear I have fixed this before, but I'm not sure what happenned to it.  Fixed
> now...again...whatever.
> 

Is the Matroska page I refered to the most up to date information 
available? You said you changed it but where is it changed?

I updated the list again, now it includes the Matroska tags as a base:
http://hobba.hobba.nl/audio/tagfields2.html

As you can see on the page I stared to use some awful colours to mark 
changed and problem area's for now. The exact legend can also be found 
on the bottom of the page.
The green area's: You seem to be using BITSPS (bits per second) but 
aren't bits per minute a more widely used unit?
You refer to the id3 CONTENTTYPE for the genre but according the the ID3 
list GENREID should be used, shouldn't it? GENRE is the actual used 
field name instead of GENREID though... Also, is there realy a need to 
use two different tags to refer to the audio and video genre? Imo it 
should be judged by the used context if it refers to audio or video.
And finally SET_PART, the current description is "the total number of 
tracks on a disc" but judging by the field name itself it's refering to 
a single part instead of the total. If the current description is 
incorrect, the field would be the same as the id3 PARTINSET field.

The yellow: CDROM_CD_TEXT_PACK_TOC_INFO2 as a field name must be the 
most self descriptive tag name ever! ;-)
I don't know it's purpose, the description is left out, but should this 
be included or shouldn't the field name be changed?

The blue area's: Isn't there a tracknumber field included in the 
Matroska tag fields? Shouldn't there be?
Also the COMMENT field, this one appears to be left out in Matroska as 
well. Imo a comment field should be included. E.g. what if you want to 
mark a track being a bonus track of a disc? Or what if the track is 
featuring a different artist?

As for the orange: Can you confirm if these field names are placed 
correctly?

Cheers,

Age


From matroska at mani.user.lysator.liu.se  Mon Mar 15 01:15:28 2004
From: matroska at mani.user.lysator.liu.se (Martin Nilsson)
Date: Mon, 15 Mar 2004 01:15:28 +0100
Subject: [Matroska-devel] Re: EBML
In-Reply-To: <c2ukb0$ha1$1@sea.gmane.org>
References: <404F85D6.2080701@mani.user.lysator.liu.se>
	<c2ukb0$ha1$1@sea.gmane.org>
Message-ID: <4054F5A0.4050906@mani.user.lysator.liu.se>

Paul Bryson wrote:

> A few quick questions, I had always thought that the CRC32 and Void elements
> were Matroska specific.  Is this the case, or are they in fact a part of the
> EBML spec?

I obviously used the current EBML web page as basis for the 
specification. I listed, besides the EBML header, CRC-32, Void and the 
signature complex. I dropped the signature stuff because I found it to 
complicated and underspecified to have in the core EBML, and I didn't 
feel like making a proper definition for it. Both CRC-32 and Void makes 
sense in a general EBML perspective, so I let them stay. Though "my" 
CRC-32 is different from the previous one (with different ID of course). 
It's of course trivial to throw them out from the general context to 
free some 1-byte IDs. Void is only useful in rewritable, big files.

> 
> For "Appendix D.  Matroska DTD", the Chapters and Tags can each be nested
> several layers deep within each other.  Is there any clean way to indicate this,
> or am I missing it?

Yes, you just declare the insertion point as parent to the element you 
would like to nest. Tell me which elements can be nested how and I'll 
fix it.

Example:

Table := 81 container [ parent:Row; ] {
   Row := 82 container {
     Cell := 83 string;
   }
}

Also note that the Matroska DTD says that the elements are ordered. I 
assume that's not the case in reality, right? (Though it would be a very 
good property IMHO) Further it is possible to make the DTD even better 
by improving the cardinality of stuff. Pretty much all elements are 
optional as it is now.

> 
> Is it necessary to define things such as how exactly a "Signed EBML Integer"
> works?

It doesn't hurt. I've added some more references now, though I can't log 
in to the webserver and update the one on the web for some reason...

> 
> And only slightly related to this, is the EBML project ever going to be moved to
> Corecodec.org, or is it going to stay on SourceForge?

And somewhat related to that is how to proceed with this EBML 
specification. I will not update it further in substance exception for 
whatever feedback I get. I will finish my DTD verifier and combine it 
with my EBML parser so that it can validate EBML data against an EBML 
DTD. An EBML test suite is probably also a good idea, which I might 
spend some time on after the draft has been officially accepted (which 
brings the question who is to officially accept it...)

/Martin Nilsson



From paul at msn.com  Mon Mar 15 06:10:18 2004
From: paul at msn.com (Paul Bryson)
Date: Sun, 14 Mar 2004 23:10:18 -0600
Subject: [Matroska-devel] Re: Re: EBML
References: <404F85D6.2080701@mani.user.lysator.liu.se><c2ukb0$ha1$1@sea.gmane.org>
	<4054F5A0.4050906@mani.user.lysator.liu.se>
Message-ID: <c33dqu$93g$1@sea.gmane.org>

"Martin Nilsson" wrote...
> Paul Bryson wrote:
>
> > A few quick questions, I had always thought that the CRC32 and Void elements
> > were Matroska specific.  Is this the case, or are they in fact a part of the
> > EBML spec?
>
> I obviously used the current EBML web page as basis for the
> specification. I listed, besides the EBML header, CRC-32, Void

Oops, I didn't notice that.  I guess that page is correct, but Steve would know
for sure.

> I dropped the signature stuff because I found it to
> complicated and underspecified to have in the core EBML, and I didn't
> feel like making a proper definition for it.

Yes, it is not even going to be in the Matroska 1.0 specs.

> Both CRC-32 and Void makes
> sense in a general EBML perspective, so I let them stay. Though "my"
> CRC-32 is different from the previous one (with different ID of course).
> It's of course trivial to throw them out from the general context to
> free some 1-byte IDs. Void is only useful in rewritable, big files.

Void certainly makes sense, and I guess that CRC-32 does too.  However, if it is
a general EBML element, it should probably be defined as what is already used.

> > For "Appendix D.  Matroska DTD", the Chapters and Tags can each be nested
> > several layers deep within each other.  Is there any clean way to indicate
this,
> > or am I missing it?
>
> Yes, you just declare the insertion point as parent to the element you
> would like to nest. Tell me which elements can be nested how and I'll
> fix it.

This needs to be clarified within the specs, so I'll try to mention it to Steve.

For the Tags:
A SimpleTag always contains a single TagName and either a TagString or a
TagBinary.  A SimpleTag can also contain another SimpleTag, which in turn MUST
include a single TagName and either a TagString or a TagBinary.  A SimpleTag can
contain any number of SimpleTag, and these levels can currently go to any depth.

For the Chapters:
For Chapters I am a little unsure so I hope someone will correct me if I am
wrong. A ChapterAtom always contains at least one ChapterUID and a
ChapterTimeStart.  It can also contain a one or more ChapterAtoms.  Like the
SimpleTag, there is currently no set limit to the number of ChapterAtoms a
ChapterAtom can contain, nor the number of levels deep that they can be
contained.

> Also note that the Matroska DTD says that the elements are ordered. I
> assume that's not the case in reality, right? (Though it would be a very
> good property IMHO)

There was some debate about this recently, and I can't recall the outcome.  In
many cases the ordering of the elements does not matter, however the way that
the Blocks for different tracks is interleaved in Clusters, and the order that
those Clusters are stored in will matter for smooth playback.  If I have time, I
will search for that posting.  I know it is in the mailing list somewhere.

> Further it is possible to make the DTD even better
> by improving the cardinality of stuff. Pretty much all elements are
> optional as it is now.

This is very problematic and can only be solved by the use of profiles.  For
instance, if you have a Matroska file containing only attachments, the only
things you would have are the EBML headers, Segment, Attachement related
elements, and the SeekHead.  At this point, the EBML headers and the Segment are
the only things that can definately be said are required.

> DTD. An EBML test suite is probably also a good idea, which I might
> spend some time on after the draft has been officially accepted (which
> brings the question who is to officially accept it...)

I am really not sure.  At this point it would probably be Steve, but he has been
busy and I guess that Christian could authorize someone else to accept it.


Pamel





From paul at msn.com  Mon Mar 15 08:34:58 2004
From: paul at msn.com (Paul Bryson)
Date: Mon, 15 Mar 2004 01:34:58 -0600
Subject: [Matroska-devel] Re: Re: Tag names
References: <40532BBD.8060909@home.nl> <c2vl69$l03$1@sea.gmane.org>
	<4054B190.7050008@home.nl>
Message-ID: <c33ma6$ndm$1@sea.gmane.org>

"Age Bosma" wrote...
> Paul Bryson wrote:
> Is the Matroska page I refered to the most up to date information
> available? You said you changed it but where is it changed?

I updated it on my harddrive, but hadn't committed to CVS yet.  Its committed
now.

> The green area's: You seem to be using BITSPS (bits per second) but
> aren't bits per minute a more widely used unit?

Perhaps you are thinking of "Beats per minute" as I have never heard of "Bits
per minute".  Bits per second refers to the bitrate, or the rate of data
transfer.  Beats per minute is an audio term refering to (I'm not even sure how
to define this).  I'm pretty sure that Matroska is supposed to have a Beats Per
Minute tag.  Is there a common one that fb2k currently stores?

> You refer to the id3 CONTENTTYPE for the genre but according the the ID3
> list GENREID should be used, shouldn't it? GENRE is the actual used
> field name instead of GENREID though... Also, is there realy a need to
> use two different tags to refer to the audio and video genre? Imo it
> should be judged by the used context if it refers to audio or video.

If a tag is set for a Chapter instead of a Track, then it becomes important to
know which you are refering to because it will refer to both a video and audio
track.  Is it a music video or a movie?

> And finally SET_PART, the current description is "the total number of
> tracks on a disc" but judging by the field name itself it's refering to
> a single part instead of the total. If the current description is
> incorrect, the field would be the same as the id3 PARTINSET field.

This is another case of a missing tag.  There are supposed to be two tags to
hold the data that might be held in the TRCK tag.  One holds the total number of
parts.  The other holds the part that this item refers to.  Unfortunately I am
not sure which exactly SET_PART refers to.  Can you think of more descriptive
names for this.  Maybe TOTAL_PARTS and PART?

> The yellow: CDROM_CD_TEXT_PACK_TOC_INFO2 as a field name must be the
> most self descriptive tag name ever! ;-)
> I don't know it's purpose, the description is left out, but should this
> be included or shouldn't the field name be changed?

That is one of those "work in progress" tags.  It refers to the second TOC for a
CD.  Unfortunately at this point I haven't been able to track down the real name
of it and this is what MS uses for their API.  So, no this doesn't need to be
the name, but I need to track down the proper name to use.

> The blue area's: Isn't there a tracknumber field included in the
> Matroska tag fields? Shouldn't there be?

Yes, there should be.  See above with the SET_PART.  I don't want to use
TRACKNUMBER however as that creates confusion with the Matroska meaning of the
word "track".

> Also the COMMENT field, this one appears to be left out in Matroska as
> well. Imo a comment field should be included. E.g. what if you want to
> mark a track being a bonus track of a disc? Or what if the track is
> featuring a different artist?

There is already a tag labelled "COMMENTS".  If a track features a different
artist, then that track should be labelled with that artist.  That information
shouldn't need to go in the COMMENTS tag.

> As for the orange: Can you confirm if these field names are placed
> correctly?

I will try to go through and confirm these when I have some time.

The three items labeled "CONTACT" should not be under the Commercial section.  I
will move them in the Matroska specs when I have some time.

Do you want to some how indicate items that would be nested tags in Matroska,
such as WWWARTIST?

I want to make some specific examples of how to use certain tags.  For instance,
take a movie, and say where to store each piece of data for that movie.  Then
take a CD, and say where to store each piece of data for that CD.  Preferably
they would each be part of a large, multi-volume set, containing all of the
different levels of titles that could be used.  Do you have any ideas of what to
use for this?


Pamel





From moritz at bunkus.org  Mon Mar 15 09:01:21 2004
From: moritz at bunkus.org (Moritz Bunkus)
Date: Mon, 15 Mar 2004 09:01:21 +0100
Subject: [Matroska-devel] EBML
In-Reply-To: <404F85D6.2080701@mani.user.lysator.liu.se>
References: <404F85D6.2080701@mani.user.lysator.liu.se>
Message-ID: <20040315080120.GH1140@bunkus.org>

Hi Martin,

I'm really sorry I haven't commented before. Please give me another day
or two to fully read your draft. I haven't forgotten it.

Mosu

-- 
If Darl McBride was in charge, he'd probably make marriage
unconstitutional too, since clearly it de-emphasizes the commercial
nature of normal human interaction, and probably is a major impediment
to the commercial growth of prostitution. - Linus Torvalds


From paul at msn.com  Mon Mar 15 09:24:35 2004
From: paul at msn.com (Paul Bryson)
Date: Mon, 15 Mar 2004 02:24:35 -0600
Subject: [Matroska-devel] Re: Re: EBML
References: <404F85D6.2080701@mani.user.lysator.liu.se><c2ukb0$ha1$1@sea.gmane.org><4054F5A0.4050906@mani.user.lysator.liu.se>
	<c33dqu$93g$1@sea.gmane.org>
Message-ID: <c33p77$t03$1@sea.gmane.org>

"Paul Bryson" wrote...
> "Martin Nilsson" wrote...
> > Also note that the Matroska DTD says that the elements are ordered. I
> > assume that's not the case in reality, right? (Though it would be a very
> > good property IMHO)
>
> There was some debate about this recently, and I can't recall the outcome.  In
> many cases the ordering of the elements does not matter, however the way that
> the Blocks for different tracks is interleaved in Clusters, and the order that
> those Clusters are stored in will matter for smooth playback.  If I have time,
I
> will search for that posting.  I know it is in the mailing list somewhere.

Found it.
http://thread.gmane.org/gmane.comp.multimedia.matroska.devel/1132


Pamel





From moritz at bunkus.org  Mon Mar 15 09:38:19 2004
From: moritz at bunkus.org (Moritz Bunkus)
Date: Mon, 15 Mar 2004 09:38:19 +0100
Subject: [Matroska-devel] Re: Re: EBML
In-Reply-To: <c33p77$t03$1@sea.gmane.org>
References: <c33dqu$93g$1@sea.gmane.org> <c33p77$t03$1@sea.gmane.org>
Message-ID: <20040315083819.GJ1140@bunkus.org>

Heya,

this I can comment on quickly before leaving for University.

> > > Also note that the Matroska DTD says that the elements are ordered. I
> > > assume that's not the case in reality, right? (Though it would be a very
> > > good property IMHO)

My take on this issue, from the thread Paul linked to:

http://article.gmane.org/gmane.comp.multimedia.matroska.devel/1177

Note that I talk about _Matroska_ there, not _EBML_. For EBML having the
same rules as XML would probably be best: the order of different
elements does matter, the order of consecutive elements of the same type
does not matter. This will not pose a problem for Matroska as what I've
outlined in the post mentioned above only restricts this further.

However, if we allow consecutive EBML elements of the same type to be in
any order we also have to allow that the DTD may restrict this. The
other way round (saying 'order of the same elements does matter, but the
DTD may overrule this') is not acceptable and would immediately render
all current Matroska files non spec compliant.

Mosu


-- 
If Darl McBride was in charge, he'd probably make marriage
unconstitutional too, since clearly it de-emphasizes the commercial
nature of normal human interaction, and probably is a major impediment
to the commercial growth of prostitution. - Linus Torvalds


From moritz at bunkus.org  Mon Mar 15 09:43:24 2004
From: moritz at bunkus.org (Moritz Bunkus)
Date: Mon, 15 Mar 2004 09:43:24 +0100
Subject: [Matroska-devel] Re: Re: EBML
In-Reply-To: <20040315083819.GJ1140@bunkus.org>
References: <c33dqu$93g$1@sea.gmane.org> <c33p77$t03$1@sea.gmane.org>
	<20040315083819.GJ1140@bunkus.org>
Message-ID: <20040315084324.GK1140@bunkus.org>

Hi,

> Note that I talk about _Matroska_ there, not _EBML_. For EBML having the
> same rules as XML would probably be best: the order of different
> elements does matter, the order of consecutive elements of the same type
> does not matter. This will not pose a problem for Matroska as what I've
> outlined in the post mentioned above only restricts this further.

Uhm right... Why do I write such bullshit?

The order of different elements in Matroska MUST NOT matter! Otherwise
almost all existing Matroska files would be non spec compliant. The
order of the same elements shoulg generally not matter either, but the
DTD must be able to set restrictions on that.

Mosu

-- 
If Darl McBride was in charge, he'd probably make marriage
unconstitutional too, since clearly it de-emphasizes the commercial
nature of normal human interaction, and probably is a major impediment
to the commercial growth of prostitution. - Linus Torvalds


From steve.lhomme at free.fr  Mon Mar 15 09:45:59 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Mon, 15 Mar 2004 09:45:59 +0100
Subject: [Matroska-devel] Re: Re: EBML
In-Reply-To: <c33dqu$93g$1@sea.gmane.org>
References: <404F85D6.2080701@mani.user.lysator.liu.se><c2ukb0$ha1$1@sea.gmane.org>	<4054F5A0.4050906@mani.user.lysator.liu.se>
	<c33dqu$93g$1@sea.gmane.org>
Message-ID: <40556D47.7060807@free.fr>

>>>A few quick questions, I had always thought that the CRC32 and Void elements
>>>were Matroska specific.  Is this the case, or are they in fact a part of the
>>>EBML spec?
>>
>>I obviously used the current EBML web page as basis for the
>>specification. I listed, besides the EBML header, CRC-32, Void
> 
> 
> Oops, I didn't notice that.  I guess that page is correct, but Steve would know
> for sure.

Void and CRC32 are indeed part of EBML.

>>Both CRC-32 and Void makes
>>sense in a general EBML perspective, so I let them stay. Though "my"
>>CRC-32 is different from the previous one (with different ID of course).
>>It's of course trivial to throw them out from the general context to
>>free some 1-byte IDs. Void is only useful in rewritable, big files.
> 
> 
> Void certainly makes sense, and I guess that CRC-32 does too.  However, if it is
> a general EBML element, it should probably be defined as what is already used.

They are both "services" for any EBML content and make sense to unify 
parsers with such features, regardless of the specific content of the 
file... Which doesn't mean you cannot add your own CRC in your format.

The Void element helps you correct any EBML file even if you don't 
understand the syntax.

The CRC32 let you have error detection that will be supported by all 
parsers (also helpful to know where an element can be voided).

> For the Tags:
> A SimpleTag always contains a single TagName and either a TagString or a
> TagBinary.  A SimpleTag can also contain another SimpleTag, which in turn MUST
> include a single TagName and either a TagString or a TagBinary.  A SimpleTag can
> contain any number of SimpleTag, and these levels can currently go to any depth.

MUST ? It cannot be void (just to indicate that the content exists with 
all "children" having the default value) ?

> For the Chapters:
> For Chapters I am a little unsure so I hope someone will correct me if I am
> wrong. A ChapterAtom always contains at least one ChapterUID and a
> ChapterTimeStart.  It can also contain a one or more ChapterAtoms.  Like the
> SimpleTag, there is currently no set limit to the number of ChapterAtoms a
> ChapterAtom can contain, nor the number of levels deep that they can be
> contained.

Correct.

>>Also note that the Matroska DTD says that the elements are ordered. I
>>assume that's not the case in reality, right? (Though it would be a very
>>good property IMHO)
> 
> 
> There was some debate about this recently, and I can't recall the outcome.  In
> many cases the ordering of the elements does not matter, however the way that
> the Blocks for different tracks is interleaved in Clusters, and the order that
> those Clusters are stored in will matter for smooth playback.  If I have time, I
> will search for that posting.  I know it is in the mailing list somewhere.

The order is needed for error correction (otherwise the CRC is wrong). 
But in the other hand when the nested EBML content is in memory (no CRC) 
the order should not matter... But in reality it imposes too much 
constraint on the parser like infinite memory. OK the CRC calculation 
also imposes this if you want to be able to handle *all* EBML files.

>>DTD. An EBML test suite is probably also a good idea, which I might
>>spend some time on after the draft has been officially accepted (which
>>brings the question who is to officially accept it...)
> 
> 
> I am really not sure.  At this point it would probably be Steve, but he has been
> busy and I guess that Christian could authorize someone else to accept it.

Well, a Matroska test suite would also be needed. And that's a *huge* 
task ! We need valid and invalid files that cover all possible cases of 
error/validity !

Right now I want to spend my time on coding other things (MPC).


From steve.lhomme at free.fr  Mon Mar 15 09:52:40 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Mon, 15 Mar 2004 09:52:40 +0100
Subject: [Matroska-devel] Re: EBML
In-Reply-To: <4054F5A0.4050906@mani.user.lysator.liu.se>
References: <404F85D6.2080701@mani.user.lysator.liu.se>	<c2ukb0$ha1$1@sea.gmane.org>
	<4054F5A0.4050906@mani.user.lysator.liu.se>
Message-ID: <40556ED8.4050501@free.fr>

> And somewhat related to that is how to proceed with this EBML 
> specification. I will not update it further in substance exception for 
> whatever feedback I get. I will finish my DTD verifier and combine it 
> with my EBML parser so that it can validate EBML data against an EBML 
> DTD. An EBML test suite is probably also a good idea, which I might 
> spend some time on after the draft has been officially accepted (which 
> brings the question who is to officially accept it...)

It would be nice to have as many people who were involved in the 
(technical) creation. I can think of :
- Paul Bryson
- Moritz Bunkus
- John Cannon
- Julien Coolos
- Frank Klemm
- Steve Lhomme

and possibly :
- Lasse Karkainen
- Ingo Ralf Blum

and any other people involved, especially the ones who developped their 
own parser (Gabest, alex, BBB).


From chris at matroska.org  Mon Mar 15 14:20:28 2004
From: chris at matroska.org (Christian HJ Wiesner)
Date: Mon, 15 Mar 2004 14:20:28 +0100
Subject: [Matroska-devel] matroska patch by BBB for FFMPEG accepted and
	applied !!
Message-ID: <4055AD9C.6070402@matroska.org>

Hi,

i have the great pleasure to announce that Ronald 'BBB' Bultje's 
matroska patch for FFMPEG was finally accepted and applied by Michael 
Niedermayer, the head FFMPEG developer. Michael had only a few minor 
critical points he wanted to have changed, and finally applied BBB's 
patch after these changes were done.

For the non-techies amongst you, FFMPEG is the most complete and 
probably also the best collection of opensource code for multimedia 
handling, its including complete MPEG1/2/4 en- and decoders ( both audio 
and video, organized in libav*codec* ), an 
AVI/MPEG/MP4/Ogg/RM/MOV/NSV/etc container handler ( demuxer for all, 
muxer for most, organized in libav*format* ), as well as decoders for 
many other video and audio formats.

Some of you may know that FFMPEG is the basis for Milan Cutka's FFDshow 
as well as for FFvfw. In principal it is now possible to include a 
matroska splitter into FFDshow, even if this makes no sense as we have a 
pretty good splitter filter, just to give you an idea.

FFMPEG is used by most opensource players, especially in the Linux world 
and if they are not DirectShow based, but players like VLC, Xine and 
mplayer are available for Windows and MacOS also, and all of them use 
FFMPEG for at least the decoding part of the majority of audio and video 
content AFAIK.

Its a great day for us that matroska has FFMPEG support now, as we can 
certainly expect wider and better player support now, and its also 
possible to concentrate matroska playback support for several important 
players in one single module, instead of having to update all the 
players independantly.

In the name of the matroska team i would like to express my highest 
appreciation to BBB for his incredible work on his matroska demuxer and 
muxer library. He made them originally for the Gstreamer multimedia 
framework and in plain C, and released them under the L-GPL license. 
Soon the idea was born to make a nice FFMPEG patch from it, and now he 
finally found the time to do it.

*BBB*, you're our hero !!! We cant thank you enough for this great 
contribution to our project and are happy to call you our friend !

Thanks for reading this short announcement

Christian
matroska project admin



From agebosma at home.nl  Mon Mar 15 16:51:14 2004
From: agebosma at home.nl (Age Bosma)
Date: Mon, 15 Mar 2004 16:51:14 +0100
Subject: [Matroska-devel] Re: Re: Tag names
In-Reply-To: <c33ma6$ndm$1@sea.gmane.org>
References: <40532BBD.8060909@home.nl>
	<c2vl69$l03$1@sea.gmane.org>	<4054B190.7050008@home.nl>
	<c33ma6$ndm$1@sea.gmane.org>
Message-ID: <4055D0F2.7020907@home.nl>

Paul Bryson wrote:

>>Is the Matroska page I refered to the most up to date information
>>available? You said you changed it but where is it changed?
> 
> I updated it on my harddrive, but hadn't committed to CVS yet.  Its committed
> now.

Ok, cool, please keep me informed of any other changes being made to 
your file later on.


>>The green area's: You seem to be using BITSPS (bits per second) but
>>aren't bits per minute a more widely used unit? 
> 
> Perhaps you are thinking of "Beats per minute" as I have never heard of "Bits
> per minute".  Bits per second refers to the bitrate, or the rate of data
> transfer.  Beats per minute is an audio term refering to (I'm not even sure how
> to define this).  I'm pretty sure that Matroska is supposed to have a Beats Per
> Minute tag.  Is there a common one that fb2k currently stores?

Yeah, you're right, my mistake, unmarked it now.
I don't know about a foobar field being used for this. Let's hope more 
people will respond in the forum thread. Maybe we should notify peter 
about the thread?

>>You refer to the id3 CONTENTTYPE for the genre but according the the ID3
>>list GENREID should be used, shouldn't it? GENRE is the actual used
>>field name instead of GENREID though... Also, is there realy a need to
>>use two different tags to refer to the audio and video genre? Imo it
>>should be judged by the used context if it refers to audio or video.
> 
> If a tag is set for a Chapter instead of a Track, then it becomes important to
> know which you are refering to because it will refer to both a video and audio
> track.  Is it a music video or a movie?

Agree

>>And finally SET_PART, the current description is "the total number of
>>tracks on a disc" but judging by the field name itself it's refering to
>>a single part instead of the total. If the current description is
>>incorrect, the field would be the same as the id3 PARTINSET field.
 >
> This is another case of a missing tag.  There are supposed to be two tags to
> hold the data that might be held in the TRCK tag.  One holds the total number of
> parts.  The other holds the part that this item refers to.  Unfortunately I am
> not sure which exactly SET_PART refers to.  Can you think of more descriptive
> names for this.  Maybe TOTAL_PARTS and PART?

I think SET_PART is self descriptive enough as it is refering to 
PARTINSET in id3. This can be used for the TRACKNUM info as well because 
it's basically the same.
Maybe TOTAL_SET_PARTS should be added for the total information.

>>The blue area's: Isn't there a tracknumber field included in the
>>Matroska tag fields? Shouldn't there be? 
> 
> Yes, there should be.  See above with the SET_PART.  I don't want to use
> TRACKNUMBER however as that creates confusion with the Matroska meaning of the
> word "track".

You got a point. See SET_PART comment again.

>>Also the COMMENT field, this one appears to be left out in Matroska as
>>well. Imo a comment field should be included. E.g. what if you want to
>>mark a track being a bonus track of a disc? Or what if the track is
>>featuring a different artist?
> 
> There is already a tag labelled "COMMENTS".  If a track features a different
> artist, then that track should be labelled with that artist.  That information
> shouldn't need to go in the COMMENTS tag.

In the current specs it's listed under Image Specific which it shouldn't 
if it can be used outside of image info as well, that's why I didn't 
include it in the first place.
As for the featuring of an artist, I must partially disagree, suppose 
you have the latest Norah Jones album, the artist of that complete album 
is Norah Jones but on one track ("number 07 - Creepen' in" to be more 
specific) Dolly Parton is singing together with her as well. Because 
Norah Jones is the main artist of that album Dolly Parton shouldn't be 
included in the main artist label just for that one song imo.
On the other hand Dolly Parton could be included in the INVOLVED_PERSON 
label for that one track but I'm not realy sure if this would be the 
best place for it. What I do know is that introducing a new label for 
this kind of information would be overkill.

> Do you want to some how indicate items that would be nested tags in Matroska,
> such as WWWARTIST?

Sure, although I don't know for sure which field should all be marked. 
I'll dig in the excel file a bit more to see what I can do.

> I want to make some specific examples of how to use certain tags.  For instance,
> take a movie, and say where to store each piece of data for that movie.  Then
> take a CD, and say where to store each piece of data for that CD.  Preferably
> they would each be part of a large, multi-volume set, containing all of the
> different levels of titles that could be used.  Do you have any ideas of what to
> use for this?

At the moment no. At least not Matroska specific.
I'll dig into that a bit more as well and try to find out how the 
Matroska tags should be set up exactly. If we work out a good system for 
Matroska this will be very useable for xml output as well and not just 
limited to Matroska. The reason why I started all this in the first 
place ;-)
If a "standard" xml output can be developed introducing a new namespace 
for it and maybe combine it with rdf and the dublincore we would have a 
very powerfull format which can be used on a very large scale. (I'll 
just keep on dreaming for now ;-) )

One final thing I would like to get off my chest. I was amazed to see 
how many tags where included in Matroska. I never expected to see an 
attempt to combine all current tags into one system.
Like mentioned in the thread you pointed to earlier the whole tag field 
stuff should be cleaned up a some stage although I agree in being 
compatible with other tag fields as well. As a step in the right 
direction we could created 2 specs. Something like "Matroska" and 
"Matroska lite" where the first one includes all the tag fields like now 
and the lite version only includes the more usefull and necessary 
fields. In the Matroska specs people will be pointed to the lite version 
as much as possible and if realy realy realy needed people can use the 
complete spec of tag fields. What's your opinion about this?

Cheers,

Age


From paul at msn.com  Mon Mar 15 17:17:24 2004
From: paul at msn.com (Paul Bryson)
Date: Mon, 15 Mar 2004 10:17:24 -0600
Subject: [Matroska-devel] Re: Re: Re: EBML
References: <404F85D6.2080701@mani.user.lysator.liu.se><c2ukb0$ha1$1@sea.gmane.org>	<4054F5A0.4050906@mani.user.lysator.liu.se><c33dqu$93g$1@sea.gmane.org>
	<40556D47.7060807@free.fr>
Message-ID: <c34ktm$58h$1@sea.gmane.org>

"Steve Lhomme" wrote...
> > For the Tags:
> > A SimpleTag always contains a single TagName and either a TagString or a
> > TagBinary.  A SimpleTag can also contain another SimpleTag, which in turn
MUST
> > include a single TagName and either a TagString or a TagBinary.  A SimpleTag
can
> > contain any number of SimpleTag, and these levels can currently go to any
depth.
>
> MUST ? It cannot be void (just to indicate that the content exists with
> all "children" having the default value) ?

Neither the SimpleTag, nor its children have a default value, so it MUST contain
valid children if it exists.  Well, I suppose it could be empty, but it would
then just be skipped.  I suppose this should be defined somewhere?


Pamel





From suiryc at yahoo.com  Mon Mar 15 17:36:22 2004
From: suiryc at yahoo.com (Cyrius)
Date: Mon, 15 Mar 2004 08:36:22 -0800 (PST)
Subject: [Matroska-devel] Re: EBML
In-Reply-To: <40556ED8.4050501@free.fr>
Message-ID: <20040315163622.69282.qmail@web12905.mail.yahoo.com>

> It would be nice to have as many people who were involved in the 
> (technical) creation. I can think of :
> - Paul Bryson
> - Moritz Bunkus
> - John Cannon
> - Julien Coolos
*cough* I'm not sure I was involved that much :p
Anyway my name is Coloos

> - Frank Klemm
> - Steve Lhomme
> 
> and possibly :
> - Lasse Karkainen
> - Ingo Ralf Blum
> 
> and any other people involved, especially the ones who developped
> their 
> own parser (Gabest, alex, BBB).


__________________________________
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com


From steve.lhomme at free.fr  Mon Mar 15 17:43:35 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Mon, 15 Mar 2004 17:43:35 +0100
Subject: [Matroska-devel] Re: Re: Tag names
In-Reply-To: <4055D0F2.7020907@home.nl>
References: <40532BBD.8060909@home.nl>	<c2vl69$l03$1@sea.gmane.org>	<4054B190.7050008@home.nl>	<c33ma6$ndm$1@sea.gmane.org>
	<4055D0F2.7020907@home.nl>
Message-ID: <4055DD37.3020808@free.fr>

Age Bosma wrote:

> One final thing I would like to get off my chest. I was amazed to see 
> how many tags where included in Matroska. I never expected to see an 
> attempt to combine all current tags into one system.
> Like mentioned in the thread you pointed to earlier the whole tag field 
> stuff should be cleaned up a some stage although I agree in being 
> compatible with other tag fields as well. As a step in the right 
> direction we could created 2 specs. Something like "Matroska" and 
> "Matroska lite" where the first one includes all the tag fields like now 
> and the lite version only includes the more usefull and necessary 
> fields. In the Matroska specs people will be pointed to the lite version 
> as much as possible and if realy realy realy needed people can use the 
> complete spec of tag fields. What's your opinion about this?

I agree. That's similar to the profiles we use for the global Matroska 
specs. There could be different profiles, maybe the same ones as we 
already use : portable/fixed devices, audio-only/video devices, 
simple/advanced devices, read-only/write devices.


From paul at msn.com  Mon Mar 15 18:39:09 2004
From: paul at msn.com (Paul Bryson)
Date: Mon, 15 Mar 2004 11:39:09 -0600
Subject: [Matroska-devel] Re: Re: Re: Tag names
References: <40532BBD.8060909@home.nl><c2vl69$l03$1@sea.gmane.org>	<4054B190.7050008@home.nl><c33ma6$ndm$1@sea.gmane.org>
	<4055D0F2.7020907@home.nl>
Message-ID: <c34pmu$k02$1@sea.gmane.org>

"Age Bosma" wrote...
> Paul Bryson wrote:
> Ok, cool, please keep me informed of any other changes being made to
> your file later on.

Can do.

> > I'm pretty sure that Matroska is supposed to have a Beats Per
> > Minute tag.  Is there a common one that fb2k currently stores?
>
> I don't know about a foobar field being used for this. Let's hope more
> people will respond in the forum thread. Maybe we should notify peter
> about the thread?

It looks like Steve wanted two fields.  From 04/14/2003:

<robUx4> anyway what is needed is the BPM and a BPM Quality value (percentage)

<robUx4> some better DJ programs might have more sophisticated things

<robUx4> (different BPM in different sections of a track)


> I think SET_PART is self descriptive enough as it is refering to
> PARTINSET in id3. This can be used for the TRACKNUM info as well because
> it's basically the same.
> Maybe TOTAL_SET_PARTS should be added for the total information.

How about PART_IN_SET and TOTAL_SET_PARTS ?

> >>Also the COMMENT field, this one appears to be left out in Matroska as
> >>well. Imo a comment field should be included. E.g. what if you want to
> >>mark a track being a bonus track of a disc? Or what if the track is
> >>featuring a different artist?
> >
> > There is already a tag labelled "COMMENTS".  If a track features a different
> > artist, then that track should be labelled with that artist.  That
information
> > shouldn't need to go in the COMMENTS tag.
>
> In the current specs it's listed under Image Specific which it shouldn't
> if it can be used outside of image info as well, that's why I didn't
> include it in the first place.

Errrr... Thats another error.  The specs right now are a bit messy as they
represent a quick copy/paste job from the old tags specs.  Thats just another
thing that needs to be moved.

> As for the featuring of an artist, I must partially disagree, suppose
> you have the latest Norah Jones album, the artist of that complete album
> is Norah Jones but on one track ("number 07 - Creepen' in" to be more
> specific) Dolly Parton is singing together with her as well. Because
> Norah Jones is the main artist of that album Dolly Parton shouldn't be
> included in the main artist label just for that one song imo.
> On the other hand Dolly Parton could be included in the INVOLVED_PERSON
> label for that one track but I'm not realy sure if this would be the
> best place for it. What I do know is that introducing a new label for
> this kind of information would be overkill.

To me it seems natural to include Dolly in the main artist label for just that
song.  Maybe we have different definitions for these tags?  This is why we need
examples.

> > Do you want to some how indicate items that would be nested tags in
Matroska,
> > such as WWWARTIST?
>
> Sure, although I don't know for sure which field should all be marked.
> I'll dig in the excel file a bit more to see what I can do.

I' afraid that you won't find any more useful information about nested tags in
those Excel files.  They only contain data from the old tag system.  I'll bet
that you could make a pretty reasonable guess as to where it would go though.

> > I want to make some specific examples of how to use certain tags.  For
instance,
> > take a movie, and say where to store each piece of data for that movie.
Then
> > take a CD, and say where to store each piece of data for that CD.
Preferably
> > they would each be part of a large, multi-volume set, containing all of the
> > different levels of titles that could be used.  Do you have any ideas of
what to
> > use for this?
>
> At the moment no. At least not Matroska specific.

A movie example would probably be Matroska specific as there is not much else in
the way of good movie tagging.  But a CD example should be able to be used for
anything.  The problem that I encountered is that it is difficult to know where
exactly specific pieces of information should be stored.  I spent weeks digging
around in different tagging specs and was still confused by many items, I am
sure that the common users don't have a chance.  I think that that is why so
many files have the wrong tags used everywhere to store information.

If we made a specific example that displayed where each piece of information
should be placed, then I think that would be the most useful document to most
users, with the table then becoming a suplement to that.

> One final thing I would like to get off my chest. I was amazed to see
> how many tags where included in Matroska. I never expected to see an
> attempt to combine all current tags into one system.
> Like mentioned in the thread you pointed to earlier the whole tag field
> stuff should be cleaned up a some stage although I agree in being
> compatible with other tag fields as well. As a step in the right
> direction we could created 2 specs. Something like "Matroska" and
> "Matroska lite" where the first one includes all the tag fields like now
> and the lite version only includes the more usefull and necessary
> fields.

Possibly the "Matroska Common Tags"?

> In the Matroska specs people will be pointed to the lite version
> as much as possible and if realy realy realy needed people can use the
> complete spec of tag fields. What's your opinion about this?

I like it.

Although, you should probably recognize that the Tags system has already been
lightened quite a bit.  Just look at the old system:
http://matroska.org/technical/specs/tagging/oldtags.html
You have all of those fields, plus the types.  It turned out to be a lot of code
to use this system, and the sheer number of data fields that could be filled in
was more than overwhelming to anyone.  We ended up dumping the whole system and
moving to the SimpleTags.  It allowed us to remove lots of fields that were made
redundant by the use on nested tags.

While all apps should support reading of all of the tags, writing apps could
remove maybe 1/4 of the fields.  Several of the fields in General would only be
written automatically by applications and never filled in by hand.  ReplayGain
info, and all of the Capture settings under Image Specific would only be filled
in by apps.  The Commercial items probably wouldn't be filled in by end users,
and some of the identifiers would only be filled in by apps.


Pamel





From paul at msn.com  Mon Mar 15 20:26:11 2004
From: paul at msn.com (Paul Bryson)
Date: Mon, 15 Mar 2004 13:26:11 -0600
Subject: [Matroska-devel] Re: Re: Re: Tag names
References: <40532BBD.8060909@home.nl><c2vl69$l03$1@sea.gmane.org>	<4054B190.7050008@home.nl><c33ma6$ndm$1@sea.gmane.org>
	<4055D0F2.7020907@home.nl>
Message-ID: <c34vvk$85v$1@sea.gmane.org>

"Age Bosma" wrote...
> Ok, cool, please keep me informed of any other changes being made to
> your file later on.

Just committed some changes.  Diffs available here:
http://cvs.corecodec.org/cgi-bin/viewcvs.cgi/matroska/doc/website/technical/specs/tagging/index.html.diff?r1=text&tr1=1.18&r2=text&tr2=1.19&diff_format=h


Pamel





From agebosma at home.nl  Tue Mar 16 13:40:31 2004
From: agebosma at home.nl (Age Bosma)
Date: Tue, 16 Mar 2004 13:40:31 +0100
Subject: [Matroska-devel] Re: Re: Re: Tag names
In-Reply-To: <c34pmu$k02$1@sea.gmane.org>
References: <40532BBD.8060909@home.nl><c2vl69$l03$1@sea.gmane.org>	<4054B190.7050008@home.nl><c33ma6$ndm$1@sea.gmane.org>	<4055D0F2.7020907@home.nl>
	<c34pmu$k02$1@sea.gmane.org>
Message-ID: <4056F5BF.3030605@home.nl>


Paul Bryson wrote:
>>>I'm pretty sure that Matroska is supposed to have a Beats Per
>>>Minute tag.  Is there a common one that fb2k currently stores?
>>
>>I don't know about a foobar field being used for this. Let's hope more
>>people will respond in the forum thread. Maybe we should notify peter
>>about the thread?
> 
> 
> It looks like Steve wanted two fields.  From 04/14/2003:
> 
> <robUx4> anyway what is needed is the BPM and a BPM Quality value (percentage)
> 
> <robUx4> some better DJ programs might have more sophisticated things
> 
> <robUx4> (different BPM in different sections of a track)

I see you added BEATS_PER_MINUTE now, to keep everything a bit more 
consistent and if you prefer this name instead of juts BPM I suggest 
BITSPS get's changed to BITS_PER_SECOND as well. Both could be changed 
to BPS and BPM as well although in case in BPM most people will know 
what it means BPS might be more confusing.

>>I think SET_PART is self descriptive enough as it is refering to
>>PARTINSET in id3. This can be used for the TRACKNUM info as well because
>>it's basically the same.
>>Maybe TOTAL_SET_PARTS should be added for the total information. 
> 
> How about PART_IN_SET and TOTAL_SET_PARTS ?

This would be two seperate names while the total is just an extend to 
the first. Therefor I would prefer SET_PART and TOTAL_SET_PARTS 
(including the s unlike in the specs now) because both will be easy to 
understand once you know one of them and this won't cause any confusion.

>>As for the featuring of an artist, I must partially disagree, suppose
>>you have the latest Norah Jones album, the artist of that complete album
>>is Norah Jones but on one track ("number 07 - Creepen' in" to be more
>>specific) Dolly Parton is singing together with her as well. Because
>>Norah Jones is the main artist of that album Dolly Parton shouldn't be
>>included in the main artist label just for that one song imo.
>>On the other hand Dolly Parton could be included in the INVOLVED_PERSON
>>label for that one track but I'm not realy sure if this would be the
>>best place for it. What I do know is that introducing a new label for
>>this kind of information would be overkill.
> 
> To me it seems natural to include Dolly in the main artist label for just that
> song.  Maybe we have different definitions for these tags?  This is why we need
> examples.

While she helped out in only one song on the album you don't see her 
name on the front cover of the album now do you? ;-)

>>One final thing I would like to get off my chest. I was amazed to see
>>how many tags where included in Matroska. I never expected to see an
>>attempt to combine all current tags into one system.
>>Like mentioned in the thread you pointed to earlier the whole tag field
>>stuff should be cleaned up a some stage although I agree in being
>>compatible with other tag fields as well. As a step in the right
>>direction we could created 2 specs. Something like "Matroska" and
>>"Matroska lite" where the first one includes all the tag fields like now
>>and the lite version only includes the more usefull and necessary
>>fields.
> 
> 
> Possibly the "Matroska Common Tags"?
> 
> 
>>In the Matroska specs people will be pointed to the lite version
>>as much as possible and if realy realy realy needed people can use the
>>complete spec of tag fields. What's your opinion about this?
> 
> 
> I like it.
> 
> Although, you should probably recognize that the Tags system has already been
> lightened quite a bit.  Just look at the old system:
> http://matroska.org/technical/specs/tagging/oldtags.html

Bloody... :-S


I updated my document again. Your changes so far are included and I'll 
mark the nested id3 fields later on today.

I would like to suggest to move the "Titles" section to the to pof the 
page or maybe underneath the "General" section. This would be a more 
logical position because it's more important compared to the rest of the 
tag fields. Also AMOUNT should maybe be placed above CURRENCY.

As for the consistent and logical naming of fields I would like to 
propose to change the following in the current specs:
- FILE -> ORIGINAL_FILE
   FILE itself doesn't say anything about the content and because 
ORIGINAL_.... is used in multiple places...
- FRAMESPS -> FRAMES_PER_SECOND
   Like BITS_PER_SECOND and BEATS_PER_MINUTE
- MOOD -> MOOD_DESCRIPTION
   I'm not a 100% sure about changing this one but desided to mention it 
anyway
- PRODUCT -> ORIGINAL_PRODUCT or maybe even ORIGINAL_PRODUCT_NAME
- INSTRUMENT -> INSTRUMENTS
- DATE_RELEASE_ORIGINAL -> DATE_ORIGINAL_RELEASE
- DATE_TAGGING -> DATE_TAGGED
- DATE_DIGITIZING -> DATE_DIGITIZED
- DATE -> DATE_START
   Because it's used in together with DATE_END
- LEAD_PERFORMER -> ARTIST
   ARTIST is used in all other tag types and means the same thing, imo 
it would be unwise to do something completely different in this case.
- ORIGINAL_TITLE
   This description is to vague and open. Maybe ORIGINAL_x shold be 
included in the specs meaning "ORIGINAL_ can be placed infront of every 
field to indicate it's origin, e.g. ORIGINAL_ALBUM, ORIGINAL_ARTIST, 
etc." it might not make sence in all cases but it can be used in almost 
all cases.
- INVOLVED_PERSON -> CREDITS
   Not sure again if this would be wise to change though.
- EDITION -> VERSION

I know, it does look a bit drastic and I may have overlooked some as 
well but I figured while we are at changing the specs we might as well 
do it right ;-)

Cheers,

Age


From agebosma at home.nl  Wed Mar 17 08:45:08 2004
From: agebosma at home.nl (Age Bosma)
Date: Wed, 17 Mar 2004 08:45:08 +0100
Subject: [Matroska-devel] Re: Re: Re: Tag names
In-Reply-To: <4056F5BF.3030605@home.nl>
References: <40532BBD.8060909@home.nl><c2vl69$l03$1@sea.gmane.org>	<4054B190.7050008@home.nl><c33ma6$ndm$1@sea.gmane.org>	<4055D0F2.7020907@home.nl>	<c34pmu$k02$1@sea.gmane.org>
	<4056F5BF.3030605@home.nl>
Message-ID: <40580204.9060800@home.nl>

Age Bosma wrote:

> I updated my document again. Your changes so far are included and I'll 
> mark the nested id3 fields later on today.
> 
> I would like to suggest to move the "Titles" section to the to pof the 
> page or maybe underneath the "General" section. This would be a more 
> logical position because it's more important compared to the rest of the 
> tag fields. Also AMOUNT should maybe be placed above CURRENCY.
> 
> As for the consistent and logical naming of fields I would like to 
> propose to change the following in the current specs:
> - FILE -> ORIGINAL_FILE
>   FILE itself doesn't say anything about the content and because 
> ORIGINAL_.... is used in multiple places...
> - FRAMESPS -> FRAMES_PER_SECOND
>   Like BITS_PER_SECOND and BEATS_PER_MINUTE
> - MOOD -> MOOD_DESCRIPTION
>   I'm not a 100% sure about changing this one but desided to mention it 
> anyway
> - PRODUCT -> ORIGINAL_PRODUCT or maybe even ORIGINAL_PRODUCT_NAME
> - INSTRUMENT -> INSTRUMENTS
> - DATE_RELEASE_ORIGINAL -> DATE_ORIGINAL_RELEASE
> - DATE_TAGGING -> DATE_TAGGED
> - DATE_DIGITIZING -> DATE_DIGITIZED
> - DATE -> DATE_START
>   Because it's used in together with DATE_END
> - LEAD_PERFORMER -> ARTIST
>   ARTIST is used in all other tag types and means the same thing, imo it 
> would be unwise to do something completely different in this case.
> - ORIGINAL_TITLE
>   This description is to vague and open. Maybe ORIGINAL_x shold be 
> included in the specs meaning "ORIGINAL_ can be placed infront of every 
> field to indicate it's origin, e.g. ORIGINAL_ALBUM, ORIGINAL_ARTIST, 
> etc." it might not make sence in all cases but it can be used in almost 
> all cases.
> - INVOLVED_PERSON -> CREDITS
>   Not sure again if this would be wise to change though.
> - EDITION -> VERSION
> 
> I know, it does look a bit drastic and I may have overlooked some as 
> well but I figured while we are at changing the specs we might as well 
> do it right ;-)

As an update about the "ORIGINAL" suggestion: what about introducing a 
new level for the "ORIGINAL_x" information?
This makes it all grouped nicely and you're again capable of specifying 
the "ORIGINAL" info of almost anything people see fit.

Age


From moritz at bunkus.org  Wed Mar 17 17:54:51 2004
From: moritz at bunkus.org (Moritz Bunkus)
Date: Wed, 17 Mar 2004 17:54:51 +0100
Subject: [Matroska-devel] EBML
In-Reply-To: <404F85D6.2080701@mani.user.lysator.liu.se>
References: <404F85D6.2080701@mani.user.lysator.liu.se>
Message-ID: <20040317165451.GN1140@bunkus.org>

Heya,

ok, I finally got my (sometimes lazy) ass over to studying your
impressive work. All in all I'm OK with what you've written, and I'm
definitely very, very glad that someone took the time to write it down
in the first place.

The only thing that crossed my mind:

3.7.  Child order property

Like I've written earlier in Matroska order does NOT matter. This may be
bad in the sense that it complicates things for demuxers, but
unfortunately it's reality already, and if we changed that then we'd
invalidate all existing Matroska files.

However, you write: "By default this restriction is imposed on all
children to all elements." Does this mean that a DTD can change that? If
yes then we don't have a problem, because the Matroska DTD will just
have to state that order does generally not matter but in the following
n cases <insert explanation here>.

But apart from that I'd say we should accept it as it is. Again, great
work.

Mosu

-- 
If Darl McBride was in charge, he'd probably make marriage
unconstitutional too, since clearly it de-emphasizes the commercial
nature of normal human interaction, and probably is a major impediment
to the commercial growth of prostitution. - Linus Torvalds


From paul at msn.com  Wed Mar 17 18:57:33 2004
From: paul at msn.com (Paul Bryson)
Date: Wed, 17 Mar 2004 11:57:33 -0600
Subject: [Matroska-devel] Re: Re: Re: Re: Tag names
References: <40532BBD.8060909@home.nl><c2vl69$l03$1@sea.gmane.org>	<4054B190.7050008@home.nl><c33ma6$ndm$1@sea.gmane.org>	<4055D0F2.7020907@home.nl><c34pmu$k02$1@sea.gmane.org>
	<4056F5BF.3030605@home.nl>
Message-ID: <c3a3h2$j96$1@sea.gmane.org>

"Age Bosma" wrote...
> I see you added BEATS_PER_MINUTE now, to keep everything a bit more
> consistent and if you prefer this name instead of juts BPM I suggest
> BITSPS get's changed to BITS_PER_SECOND as well. Both could be changed
> to BPS and BPM as well although in case in BPM most people will know
> what it means BPS might be more confusing.

The BITSPS can't be changed because it is already being used.  However, the
BEATS_PER_MINUTE could be changed to either BPM or BEATSPM if you think one or
the other makes more sense.

> This would be two seperate names while the total is just an extend to
> the first. Therefor I would prefer SET_PART and TOTAL_SET_PARTS
> (including the s unlike in the specs now) because both will be easy to
> understand once you know one of them and this won't cause any confusion.

Despite what I wrote in the email, I actually put this in the specs:

SET_PART
TOTAL_SET_PARTS
MEDIA_PART
TOTAL_MEDIA_PARTS

These should cover both the TRCK and TPOS tags in ID3.

> While she helped out in only one song on the album you don't see her
> name on the front cover of the album now do you? ;-)

No, but I am guessing that her name is in the booklet under that song. I'm sure
that if you did a poll, you would find that there are a lot of people that would
store this information under different places.  We really need examples to say
what is appropriate.

> I would like to suggest to move the "Titles" section to the to pof the
> page or maybe underneath the "General" section. This would be a more
> logical position because it's more important compared to the rest of the
> tag fields. Also AMOUNT should maybe be placed above CURRENCY.

Done.

> As for the consistent and logical naming of fields I would like to
> propose to change the following in the current specs:
> - FILE -> ORIGINAL_FILE
>    FILE itself doesn't say anything about the content and because
> ORIGINAL_.... is used in multiple places...

Done.

> - FRAMESPS -> FRAMES_PER_SECOND
>    Like BITS_PER_SECOND and BEATS_PER_MINUTE

This field is already used so it can't be changed.  However, we need to clarify
how to use it.

> - MOOD -> MOOD_DESCRIPTION
>    I'm not a 100% sure about changing this one but desided to mention it
> anyway

They have the same meaning in my mind so I don't see a reason to change it.

> - PRODUCT -> ORIGINAL_PRODUCT or maybe even ORIGINAL_PRODUCT_NAME

Perhaps, given the description, it should be INTENDED_PRODUCT?  This tag comes
from the RIFF specs and I couldn't find a very good description of it.

> - INSTRUMENT -> INSTRUMENTS

This change might induce somebody to store more than one instrument in a tag,
which is a no-no.  From the specs, "Multiple items should never be stored as a
list in a single TagString."

> - DATE_RELEASE_ORIGINAL -> DATE_ORIGINAL_RELEASE

Is that really better with DATE_RELEASE just above it?  To my eyes it looks
better this way, but I am not sure.  I asked in IRC and one person responded
that they prefer DRO.  "don't you like french word order?"

> - DATE_TAGGING -> DATE_TAGGED
> - DATE_DIGITIZING -> DATE_DIGITIZED

Makes sense, changed.

> - DATE -> DATE_START
>    Because it's used in together with DATE_END

I originally started with DATE_START but changed it.  It makes little sense for
most items where you only tag a single date, and not a start and end date.

> - LEAD_PERFORMER -> ARTIST

Should a difference be made between lead performer and other performers?

>    ARTIST is used in all other tag types and means the same thing, imo
> it would be unwise to do something completely different in this case.

I assumed it was the same as the ID3v2 TPE1 tag, the Vorbis PERFORMER tag, the
CD CDROM_CD_TEXT_PACK_PERFORMER tag, and the RIFF ISTR tag?  Should there be a
difference between a lead performer and any other artist?

> - ORIGINAL_TITLE
>    This description is to vague and open. Maybe ORIGINAL_x shold be
> included in the specs meaning "ORIGINAL_ can be placed infront of every
> field to indicate it's origin, e.g. ORIGINAL_ALBUM, ORIGINAL_ARTIST,
> etc." it might not make sence in all cases but it can be used in almost
> all cases.

In some cases the "ORIGINAL" title is used for remakes (ORIGINAL_ARTIST).  In
others it is used to denote the source (ORIGINAL_FILE).  I would hate for these
two to get confused.  Is there something that you could recommend?

> - INVOLVED_PERSON -> CREDITS
>    Not sure again if this would be wise to change though.

I think that CREDITS sounds better and would probably be more intuitive, but it
would probably induce people to store a list in a single tag instead of multiple
tags.

> - EDITION -> VERSION

For DVDs, this is always referred to as the Edition.  For instance, I have DVDs
that are "Directors Cut", "Collector's", "Ultimate", and various other editions.
Is this done differently with CDs?

One other thing, where should we store if a source was widescreen or fullscreen?
And I mean in a generic sense.  The dimensional proportions could always go in
ORIGINAL_DIMENSIONS.  Should there be a different place where someone could just
write "Widescreen" or "Fullscreen"?  Maybe "Anamorphic Widescreen" (1.66:1 to
2.35:1) and "Full Frame" (1.33:1)?

How would you store this DVD of mine?
Bruce Campbell vs. Army Of Darkness
The Director' Cut
Official Bootleg Edition
Widescreen Presentation

Photos available here:
http://www.jkfanclub.com:81/matroska/Projects/Photos/
And yes, the DVD actually says "DVD-R4x Not Really Recordable 96 MIN" and
"Un-Recordable 1x-4x Compatible"


Pamel





From steve.lhomme at free.fr  Wed Mar 17 19:31:35 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Wed, 17 Mar 2004 19:31:35 +0100
Subject: [Matroska-devel] EBML
In-Reply-To: <20040317165451.GN1140@bunkus.org>
References: <404F85D6.2080701@mani.user.lysator.liu.se>
	<20040317165451.GN1140@bunkus.org>
Message-ID: <40589987.3060004@free.fr>

Moritz Bunkus wrote:
> 3.7.  Child order property
> 
> Like I've written earlier in Matroska order does NOT matter. This may be
> bad in the sense that it complicates things for demuxers, but
> unfortunately it's reality already, and if we changed that then we'd
> invalidate all existing Matroska files.
> 
> However, you write: "By default this restriction is imposed on all
> children to all elements." Does this mean that a DTD can change that? If
> yes then we don't have a problem, because the Matroska DTD will just
> have to state that order does generally not matter but in the following
> n cases <insert explanation here>.

IIRC with a DTD, elements have to be ordered. There is no such 
limitation with Schemas. But maybe I'm wrong (after all you don't have 
to order <h1> and <p> in XHTML with is described with a DTD).



From agebosma at home.nl  Wed Mar 17 23:14:23 2004
From: agebosma at home.nl (Age Bosma)
Date: Wed, 17 Mar 2004 23:14:23 +0100
Subject: [Matroska-devel] Re: Re: Re: Re: Tag names
In-Reply-To: <c3a3h2$j96$1@sea.gmane.org>
References: <40532BBD.8060909@home.nl><c2vl69$l03$1@sea.gmane.org>	<4054B190.7050008@home.nl><c33ma6$ndm$1@sea.gmane.org>	<4055D0F2.7020907@home.nl><c34pmu$k02$1@sea.gmane.org>	<4056F5BF.3030605@home.nl>
	<c3a3h2$j96$1@sea.gmane.org>
Message-ID: <4058CDBF.7020905@home.nl>

Paul Bryson wrote:
> The BITSPS can't be changed because it is already being used.  However, the
> BEATS_PER_MINUTE could be changed to either BPM or BEATSPM if you think one or
> the other makes more sense.

Too bad :-(
In that cse I would prefer BEATSPM to stay consistent with the FRAMESPS 
and BITSPS.

>>This would be two seperate names while the total is just an extend to
>>the first. Therefor I would prefer SET_PART and TOTAL_SET_PARTS
>>(including the s unlike in the specs now) because both will be easy to
>>understand once you know one of them and this won't cause any confusion.
> 
> 
> Despite what I wrote in the email, I actually put this in the specs:
> 
> SET_PART
> TOTAL_SET_PARTS
> MEDIA_PART
> TOTAL_MEDIA_PARTS
> 
> These should cover both the TRCK and TPOS tags in ID3.

I noticed. Because you mentioned it in the e-mail made it unclear if you 
where still in doubt about that one.

>>While she helped out in only one song on the album you don't see her
>>name on the front cover of the album now do you? ;-)
> 
> No, but I am guessing that her name is in the booklet under that song. I'm sure
> that if you did a poll, you would find that there are a lot of people that would
> store this information under different places.  We really need examples to say
> what is appropriate.

INVOLVED_PERSON would be a good place to store it but that name isn't 
very descriptive in this case. We could just change that on to FEATURING 
but I don't know if it would couse problems in other cases.

>>- PRODUCT -> ORIGINAL_PRODUCT or maybe even ORIGINAL_PRODUCT_NAME
> 
> Perhaps, given the description, it should be INTENDED_PRODUCT?  This tag comes
> from the RIFF specs and I couldn't find a very good description of it.

You got a point, my Enlish isn't perfect but wouldn't DESIGNATED_PRODUCT 
be even better? If no, INTENDED_PRODUCT is just fine.

>>- INSTRUMENT -> INSTRUMENTS
> 
> This change might induce somebody to store more than one instrument in a tag,
> which is a no-no.  From the specs, "Multiple items should never be stored as a
> list in a single TagString."

The reason I mentioned it was because it doesn't happen a lot that only 
one instrument is used in a song. Therefor it should be made clear it's 
possible (by an example again as well) to use the field multiple time if 
that's the case in the first place.

>>- DATE_RELEASE_ORIGINAL -> DATE_ORIGINAL_RELEASE
> 
> Is that really better with DATE_RELEASE just above it?  To my eyes it looks
> better this way, but I am not sure.  I asked in IRC and one person responded
> that they prefer DRO.  "don't you like french word order?"

I prefer sticking to the main sequence in which the word ORIGINAL_ is 
used in the other fields. In this case you (probably) want to keep DATE_ 
in front otherwise I would have changed it to ORIGINAL_RELEASE_DATE.
And no, I don't like french word order (no offence intended). ;-)

>>- DATE -> DATE_START
>>   Because it's used in together with DATE_END 
> 
> I originally started with DATE_START but changed it.  It makes little sense for
> most items where you only tag a single date, and not a start and end date.
> 

Agree

>>- LEAD_PERFORMER -> ARTIST 
> 
> Should a difference be made between lead performer and other performers? 
> 
>>ARTIST is used in all other tag types and means the same thing, imo
>>it would be unwise to do something completely different in this case.
> 
> 
> I assumed it was the same as the ID3v2 TPE1 tag, the Vorbis PERFORMER tag, the
> CD CDROM_CD_TEXT_PACK_PERFORMER tag, and the RIFF ISTR tag?  Should there be a
> difference between a lead performer and any other artist?

It's not the same as the Vorbis PERFORMER tag as you look at the 
descriptions closely, this field should be placed with CONDUCTOR like in 
my reference. Also for ID3 and APE ARTIST are the only fields that come 
close enough to the LEAD_PERFORMER Matroska field.
 From a e.g. a jazz point of view you may speak about LEAD_PERFORMER 
together with BAND but everyone will know what you mean if you use 
ARTIST and BAND in this case as well. This makes it possible to use the 
ARTIST field for e.g. just "Dire Straits" or "Slipknot" as well and 
therefor being fully compatible with the other tag types. Using 
LEAD_PERFORMER in a "Dire Straits" or "Slipknot" context makes much less 
sense.

>>- ORIGINAL_TITLE
>>   This description is to vague and open. Maybe ORIGINAL_x shold be
>>included in the specs meaning "ORIGINAL_ can be placed infront of every
>>field to indicate it's origin, e.g. ORIGINAL_ALBUM, ORIGINAL_ARTIST,
>>etc." it might not make sence in all cases but it can be used in almost
>>all cases.
> 
> In some cases the "ORIGINAL" title is used for remakes (ORIGINAL_ARTIST).  In
> others it is used to denote the source (ORIGINAL_FILE).  I would hate for these
> two to get confused.  Is there something that you could recommend?

It's still basicly the same imo. Did you read my other extra post about 
this? If we include a new level for all "original" info this would rule 
out confusion and clean up a lot of fields we have at the moment.

>>- INVOLVED_PERSON -> CREDITS
>>   Not sure again if this would be wise to change though.
> 
> I think that CREDITS sounds better and would probably be more intuitive, but it
> would probably induce people to store a list in a single tag instead of multiple
> tags.

Drop it completely and add FEATURING like mentioned earlier in this mail.

>>- EDITION -> VERSION
> 
> For DVDs, this is always referred to as the Edition.  For instance, I have DVDs
> that are "Directors Cut", "Collector's", "Ultimate", and various other editions.
> Is this done differently with CDs?

If it comes to songs I think VERSION would be more suitable. Like "Fear 
Factory - New Breed (Spoetnik Mix)" or "Linkin Park - Dedicated (Demo 
1999)". They talk about different versions of the song. If you look 
strictly at the definition of both words VERSION would be more suitable 
in both cases, dvd and audio.
Maybe we should think about a more general name for this instead.

> One other thing, where should we store if a source was widescreen or fullscreen?
> And I mean in a generic sense.  The dimensional proportions could always go in
> ORIGINAL_DIMENSIONS.  Should there be a different place where someone could just
> write "Widescreen" or "Fullscreen"?  Maybe "Anamorphic Widescreen" (1.66:1 to
> 2.35:1) and "Full Frame" (1.33:1)?

That would be a duplicate entry. I think only the ratio will be fine 
because most people using terms like "widescreen" or "fullscreen" will 
probably know what they are talking about and therefor know the ratio as 
well. If we give people an extra option they will most likely leave out 
the actual ratio which imo will describe it more accurately and will 
rule out any mistakes.

> How would you store this DVD of mine?
> Bruce Campbell vs. Army Of Darkness
> The Director' Cut
> Official Bootleg Edition
> Widescreen Presentation
> 
> Photos available here:
> http://www.jkfanclub.com:81/matroska/Projects/Photos/
> And yes, the DVD actually says "DVD-R4x Not Really Recordable 96 MIN" and
> "Un-Recordable 1x-4x Compatible"

I'll work on a sample tomorrow, the site with the photo's is down and 
it's getting late. ;-)

Age


From moritz at bunkus.org  Thu Mar 18 09:10:22 2004
From: moritz at bunkus.org (Moritz Bunkus)
Date: Thu, 18 Mar 2004 09:10:22 +0100
Subject: [Matroska-devel] EBML
In-Reply-To: <405943C9.9090405@pike.ida.liu.se>
References: <404F85D6.2080701@mani.user.lysator.liu.se>
	<20040317165451.GN1140@bunkus.org>
	<405943C9.9090405@pike.ida.liu.se>
Message-ID: <20040318081022.GP1140@bunkus.org>

Hi,

> At least if the Matroska files really have different element order in 
> practice...

They do. The three 'major' muxers (Alexander Noe's AVI-Mux GUI, Gabest's
DirectShow Matroska muxer and my mkvmerge) all produce files in which
elements are ordered differently. And order does not make sense
everywhere! It might make sense for the 'smaller' units like block
groups, track headers etc. But for the KaxSegment (level 1 elements) it
does not make any sense at all - we'd lose flexibility. We have the
seekheads for locating level 1 elements, so finding them isn't a problem
either.

> >However, you write: "By default this restriction is imposed on all
> >children to all elements." Does this mean that a DTD can change that?
> 
> Yes.

Then we don't really have a problem.

Mosu

-- 
If Darl McBride was in charge, he'd probably make marriage
unconstitutional too, since clearly it de-emphasizes the commercial
nature of normal human interaction, and probably is a major impediment
to the commercial growth of prostitution. - Linus Torvalds
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20040318/766334b3/attachment.pgp>

From moritz at bunkus.org  Thu Mar 18 09:13:04 2004
From: moritz at bunkus.org (Moritz Bunkus)
Date: Thu, 18 Mar 2004 09:13:04 +0100
Subject: [moritz@bunkus.org: Re: [Matroska-devel] Re: Re: EBML]
Message-ID: <20040318081304.GQ1140@bunkus.org>

Should have gone to the ML...

-- 
If Darl McBride was in charge, he'd probably make marriage
unconstitutional too, since clearly it de-emphasizes the commercial
nature of normal human interaction, and probably is a major impediment
to the commercial growth of prostitution. - Linus Torvalds
-------------- next part --------------
An embedded message was scrubbed...
From: Moritz Bunkus <moritz at bunkus.org>
Subject: Re: [Matroska-devel] Re: Re: EBML
Date: Thu, 18 Mar 2004 09:06:22 +0100
Size: 2493
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20040318/7cd3ab4a/attachment.mht>

From steve.lhomme at free.fr  Thu Mar 18 09:43:37 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Thu, 18 Mar 2004 09:43:37 +0100
Subject: [Matroska-devel] Re: EBML
In-Reply-To: <20040318081304.GQ1140@bunkus.org>
References: <20040318081304.GQ1140@bunkus.org>
Message-ID: <40596139.3020609@free.fr>

>>It is however intresting to see that you make a distinction between
>>elements of the same type and elements of different types. It is
>>currently not possible to differentiate between them in the DTD, which
>>may be a problem.

IMO this distinction also applies to HTML :
<ul>
<li>item</li>
some text
</ul>

can produce either :
* item
some text

or :

some text
* item

> In Matroska the order of elements does not matter. That's the
> rule. Example: In the video track headers you may put the width before
> the height but also the other way round. The exceptions are what I've
> linked to: the clusters and the blocks inside a cluster. Those SHOULD be
> ordered according to their timecodes (it's a bit more complex) in order
> to make playback as easy as possible.
> 
> If we allowed any order for these elements as well a Matroska compliant
> player would have to support playing files in which the blocks are
> ordered in descendingly...

Mmm, not exactly true. Clusters have to be consecutive. But that's 
probably part of the distinction between the same element at the same 
level and other elements.

As a side note, in libmatroska there is the possibility to reorder Cue 
entries so that they are consecutive. That was done to avoid reordering 
of such a big list on the parser side. I don't know if all existing 
parsers assume such an order or not...


From matroska at mani.user.lysator.liu.se  Thu Mar 18 10:27:18 2004
From: matroska at mani.user.lysator.liu.se (Martin Nilsson)
Date: Thu, 18 Mar 2004 10:27:18 +0100
Subject: [Matroska-devel] Re: EBML
In-Reply-To: <40596139.3020609@free.fr>
References: <20040318081304.GQ1140@bunkus.org> <40596139.3020609@free.fr>
Message-ID: <40596B76.9030602@mani.user.lysator.liu.se>

Steve Lhomme wrote:

> 
> IMO this distinction also applies to HTML :
> <ul>
> <li>item</li>
> some text
> </ul>
> 

This is a bad example. You are not allowed to have text nodes directly 
in the ul-node, so it is only natural that different clients behave 
differently (since the behaviour isn't defined).

/Martin Nilsson



From steve.lhomme at free.fr  Thu Mar 18 10:32:14 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Thu, 18 Mar 2004 10:32:14 +0100
Subject: [Matroska-devel] Re: EBML
In-Reply-To: <40596B76.9030602@mani.user.lysator.liu.se>
References: <20040318081304.GQ1140@bunkus.org> <40596139.3020609@free.fr>
	<40596B76.9030602@mani.user.lysator.liu.se>
Message-ID: <40596C9E.7010703@free.fr>

Martin Nilsson wrote:

> Steve Lhomme wrote:
> 
>>
>> IMO this distinction also applies to HTML :
>> <ul>
>> <li>item</li>
>> some text
>> </ul>
>>
> 
> This is a bad example. You are not allowed to have text nodes directly 
> in the ul-node, so it is only natural that different clients behave 
> differently (since the behaviour isn't defined).

This is HTML, not XHTML. Lots of people use it. And even with a <p></p> 
around it, the behaviour can be different depending on the browser 
(behaviour not covered by the DTD).


From matroska at mani.user.lysator.liu.se  Thu Mar 18 11:09:08 2004
From: matroska at mani.user.lysator.liu.se (Martin Nilsson)
Date: Thu, 18 Mar 2004 11:09:08 +0100
Subject: [Matroska-devel] Re: EBML
In-Reply-To: <40596C9E.7010703@free.fr>
References: <20040318081304.GQ1140@bunkus.org> <40596139.3020609@free.fr>
	<40596B76.9030602@mani.user.lysator.liu.se>
	<40596C9E.7010703@free.fr>
Message-ID: <40597544.9080700@mani.user.lysator.liu.se>

Steve Lhomme wrote:

> This is HTML, not XHTML. Lots of people use it. And even with a <p></p> 
> around it, the behaviour can be different depending on the browser 
> (behaviour not covered by the DTD).

Yes, but that doesn't alter the fact that it is invalid HTML and that 
the behaviour isn't defined in any standard. HTML 2.0 defines ul as:

<!ELEMENT (OL|UL) - -  (LI)+>

I.e. an UL element must only contain one or more LI elements. If that is 
not the case the client may do whatever it wants; e.g. print out the 
contents as best as I can, show dacing rodents or dump core.

/Martin Nilsson




From R.S.Bultje at students.uu.nl  Thu Mar 18 21:32:57 2004
From: R.S.Bultje at students.uu.nl (Ronald S. Bultje)
Date: Thu, 18 Mar 2004 21:32:57 +0100
Subject: [Matroska-devel] Re: [gst-devel] Gstreamer and matroska - the
	opensource answer to VideoforWindows/AVI and Quicktime/MOV ?
In-Reply-To: <40338455.3050905@matroska.org>
References: <40338455.3050905@matroska.org>
Message-ID: <1079641977.2412.1.camel@shrek.bitfreak.net>

Hi Chris,

the long-awaited answer that I promised a while ago. Please note that I
speak on personal title only, as a GStreamer developer, but not as a
GStreamer representative as such.

I'll first answer your brainstorming by explaining what GStreamer's aim
is: it is world domination. My personal goals are much simpler. I am
interested solely in the Linux platform, for any supported arch out
there, and my personal goal is to bring media to the desktop on this
wonderful OS. If it runs on any other OS, I'll be happy for the people
that care, but I won't care much myself. As a user, I'm specifically
attracted to GNOME/GStreamer as a combination. As a developer, I have an
interest for KDE/GStreamer, too. Quicktime/Directshow are nothing more
than vague alternatives for me on other OSes. I don't know them, nor do
I want to.

GStreamer is not bound to a single container, nor does it need a
preferred one. Users use individually preferred containers. If we would
ever want to set automated preferences (planned for 0.9.x by me), I'd
give any open format a higher preference than a closed one. Obviously,
(example) Matroska would be preferred over (example) ASF. However, Ogg
and Matroska would be evenly preferred. I don't want to bind to a single
container because I don't see that as an obvious task for a media
framework.

On Wed, 2004-02-18 at 16:27, Christian HJ Wiesner wrote:
[..] 
> I am well aware gstreamer doesnt need matroska at all. Your way is 
> clear, becoming the best media framework for the Linux world, and you 
> guys wont mind if your project is ported to other OSes also, as this can 
> only help you to achieve your goals, for sure. You could also settle for 
> MOV as standard container, as there are currently no features realized 
> in matroska that MOV cant do also, or have no standard container at all. 
> On the other hand, you could win a couple of contributors and fans with 
> such an 'alliance', if you allow me to name it like that. Opinions 
> please, and use the 'reply all' button if i may ask for that, to copy 
> both lists. Stupid idea ? Useless ? Possible ? Tell me what you think ....

Nice marketing try ( ;) ), but it's not what I'd want.

Ronald 


From paul at msn.com  Fri Mar 19 04:28:26 2004
From: paul at msn.com (Paul Bryson)
Date: Thu, 18 Mar 2004 21:28:26 -0600
Subject: [Matroska-devel] Re: [gst-devel] Gstreamer and matroska -
	theopensource answer to VideoforWindows/AVI and Quicktime/MOV ?
References: <40338455.3050905@matroska.org>
	<1079641977.2412.1.camel@shrek.bitfreak.net>
Message-ID: <c3dpcm$3rg$1@sea.gmane.org>

"Ronald S. Bultje" wrote...
> GStreamer is not bound to a single container, nor does it need a
> preferred one. Users use individually preferred containers. If we would
> ever want to set automated preferences (planned for 0.9.x by me), I'd
> give any open format a higher preference than a closed one. Obviously,
> (example) Matroska would be preferred over (example) ASF. However, Ogg
> and Matroska would be evenly preferred.

I would prefer most things over Ogg because at this point it only stores Vorbis,
and soon officially Theora.  Perhaps Matroska and NUT would be evenly preferred?
Although, I imagine that (like every other program) GStreamer would only allow
selecting a single initial default.  But what would you pick?  If you would
indeed prefer an open format, then Matroska seems the obvious choice here.  It
will store anything, and is already in 'wide spread' use.


Pamel





From R.S.Bultje at students.uu.nl  Thu Mar 18 22:58:11 2004
From: R.S.Bultje at students.uu.nl (Ronald S. Bultje)
Date: Thu, 18 Mar 2004 22:58:11 +0100
Subject: [Matroska-devel] Re: [gst-devel] Gstreamer and matroska -
	theopensource answer to VideoforWindows/AVI and Quicktime/MOV ?
In-Reply-To: <c3dpcm$3rg$1@sea.gmane.org>
References: <40338455.3050905@matroska.org>
	<1079641977.2412.1.camel@shrek.bitfreak.net>
	<c3dpcm$3rg$1@sea.gmane.org>
Message-ID: <1079647091.2412.28.camel@shrek.bitfreak.net>

On Fri, 2004-03-19 at 04:28, Paul Bryson wrote:
> I would prefer most things over Ogg because at this point it only stores Vorbis,
> and soon officially Theora.  Perhaps Matroska and NUT would be evenly preferred?
> Although, I imagine that (like every other program) GStreamer would only allow
> selecting a single initial default.  But what would you pick?  If you would
> indeed prefer an open format, then Matroska seems the obvious choice here.  It
> will store anything, and is already in 'wide spread' use.

We don't. We let the app decide, we let randomness decide, we let the
alphabet decide, I don't know. We won't have any official "GStreamer
file format" like Quicktime of VfW which is widely advertised on our
website, in each of our apps, etc. If we ever set "ranking icons" for
favoured or unfavoured formats, Matroska will get the same icon as other
container formats that meet our requirements similarly well. Etc.

Ogg is evenly preferred because it allows for storage of video and audio
using open container, video and audio codec. That's good enough. Note
that we don't have an Ogg muxer yet, though we're eagerly awaiting one.

Nut is currently vapourware (or under development; whichever you
prefer), see Michael's comments several months ago on ffmpeg-devel at .
Besides, we don't have a Nut muxer.

Ronald



From paul at msn.com  Fri Mar 19 05:41:36 2004
From: paul at msn.com (Paul Bryson)
Date: Thu, 18 Mar 2004 22:41:36 -0600
Subject: [Matroska-devel] Re: Re: [gst-devel] Gstreamer and matroska
	-theopensource answer to VideoforWindows/AVI and Quicktime/MOV ?
References: <40338455.3050905@matroska.org><1079641977.2412.1.camel@shrek.bitfreak.net><c3dpcm$3rg$1@sea.gmane.org>
	<1079647091.2412.28.camel@shrek.bitfreak.net>
Message-ID: <c3dtlr$atu$1@sea.gmane.org>

"Ronald S. Bultje" wrote...
> We don't. We let the app decide, we let randomness decide,

What a very strange program.  "Behaviour differs on each run to keep things
interesting".  A little like DirectShow, but apparently intentional.

> We won't have any official "GStreamer file format"

Its not so much of an 'official', but what comes up as a default on the first
run.  Alphabet is also a good way, although the user may unknowingly choose
incompatible items this way.  (think AVI)

> Ogg is evenly preferred because it allows for storage of video and audio

The only codec that I have ever seen in Ogg is Vorbis, although I understand
that it actually supports a few other Xiph endorsed audio codecs.  Where is this
Ogg Video file that you speak of?  (remembering of course that Ogg != OGM)

> Besides, we don't have a Nut muxer.

I would like to thank spyder482 for not actually releasing the NUT muxer that he
wrote.  ;)


Pamel





From spyder at matroska.org  Fri Mar 19 06:06:31 2004
From: spyder at matroska.org (John Cannon)
Date: Thu, 18 Mar 2004 23:06:31 -0600
Subject: [Matroska-devel] Re: Re: [gst-devel] Gstreamer and
	matroska	-theopensource
	answer to VideoforWindows/AVI and Quicktime/MOV ?
In-Reply-To: <c3dtlr$atu$1@sea.gmane.org>
References: <40338455.3050905@matroska.org><1079641977.2412.1.camel@shrek.bitfreak.net><c3dpcm$3rg$1@sea.gmane.org>	<1079647091.2412.28.camel@shrek.bitfreak.net>
	<c3dtlr$atu$1@sea.gmane.org>
Message-ID: <405A7FD7.3050000@matroska.org>

Paul Bryson wrote:

>>Besides, we don't have a Nut muxer.
>>    
>>
>
>I would like to thank spyder482 for not actually releasing the NUT muxer that he
>wrote.  ;)
>
>  
>
You're very very welcome ;)  I'm just thinking of the old people ;)

John


From steve.lhomme at free.fr  Fri Mar 19 09:30:36 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Fri, 19 Mar 2004 09:30:36 +0100
Subject: [Matroska-devel] Re: [gst-devel] Gstreamer and matroska - the
	opensource answer to VideoforWindows/AVI and Quicktime/MOV ?
In-Reply-To: <1079641977.2412.1.camel@shrek.bitfreak.net>
References: <40338455.3050905@matroska.org>
	<1079641977.2412.1.camel@shrek.bitfreak.net>
Message-ID: <405AAFAC.3060100@free.fr>

Ronald S. Bultje wrote:

> I'll first answer your brainstorming by explaining what GStreamer's aim
> is: it is world domination. My personal goals are much simpler. I am

He he.

> interested solely in the Linux platform, for any supported arch out
> there, and my personal goal is to bring media to the desktop on this
> wonderful OS. If it runs on any other OS, I'll be happy for the people
> that care, but I won't care much myself. As a user, I'm specifically
> attracted to GNOME/GStreamer as a combination. As a developer, I have an
> interest for KDE/GStreamer, too. Quicktime/Directshow are nothing more
> than vague alternatives for me on other OSes. I don't know them, nor do
> I want to.

Too bad, you should learn the lessons from the past. Personally I 
learned a lot from the BeOS Media Kit even though I never worked with it.


From steve.lhomme at free.fr  Fri Mar 19 09:34:22 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Fri, 19 Mar 2004 09:34:22 +0100
Subject: [Matroska-devel] Re: Gstreamer and matroska	-theopensource answer
 to VideoforWindows/AVI and Quicktime/MOV ?
In-Reply-To: <c3dtlr$atu$1@sea.gmane.org>
References: <40338455.3050905@matroska.org><1079641977.2412.1.camel@shrek.bitfreak.net><c3dpcm$3rg$1@sea.gmane.org>	<1079647091.2412.28.camel@shrek.bitfreak.net>
	<c3dtlr$atu$1@sea.gmane.org>
Message-ID: <405AB08E.3080002@free.fr>

> The only codec that I have ever seen in Ogg is Vorbis, although I understand
> that it actually supports a few other Xiph endorsed audio codecs.  Where is this
> Ogg Video file that you speak of?  (remembering of course that Ogg != OGM)

Just as a reminder for us (and how somehow long history), Xiph once 
promised to come up with a spec for video content in Ogg and that OGM 
was close to what they have in mind. It was at least 6 months ago and 
nothing happened. Now figure out where the vapourware comes out. ;) (no 
I will never forgive them for this state of mind)


From chris at matroska.org  Fri Mar 19 10:23:03 2004
From: chris at matroska.org (Christian HJ Wiesner)
Date: Fri, 19 Mar 2004 10:23:03 +0100
Subject: [Matroska-devel] Updating  features.html
Message-ID: <405ABBF7.5030604@matroska.org>

http://matroska.org/features.html

Should we abandon this overview, or update it ?

Christian



From steve.lhomme at free.fr  Fri Mar 19 10:25:46 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Fri, 19 Mar 2004 10:25:46 +0100
Subject: [Matroska-devel] Updating  features.html
In-Reply-To: <405ABBF7.5030604@matroska.org>
References: <405ABBF7.5030604@matroska.org>
Message-ID: <405ABC9A.4000307@free.fr>

IMo we should update it.

Christian HJ Wiesner wrote:

> http://matroska.org/features.html
> 
> Should we abandon this overview, or update it ?
> 
> Christian
> 
> _______________________________________________
> Matroska-devel mailing list
> Matroska-devel at lists.matroska.org
> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel


From moritz at bunkus.org  Fri Mar 19 11:06:32 2004
From: moritz at bunkus.org (Moritz Bunkus)
Date: Fri, 19 Mar 2004 11:06:32 +0100
Subject: [Matroska-devel] Updating  features.html
In-Reply-To: <405ABC9A.4000307@free.fr>
References: <405ABBF7.5030604@matroska.org> <405ABC9A.4000307@free.fr>
Message-ID: <20040319100632.GZ1140@bunkus.org>

Heya,

I'd vote for 'update' as well. Maybe we could also add some kind of
'plans for the near future' row, or a section for it under the table. We
should also state that these features are advanced features.

Mosu

-- 
If Darl McBride was in charge, he'd probably make marriage
unconstitutional too, since clearly it de-emphasizes the commercial
nature of normal human interaction, and probably is a major impediment
to the commercial growth of prostitution. - Linus Torvalds


From steve.lhomme at free.fr  Fri Mar 19 11:07:02 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Fri, 19 Mar 2004 11:07:02 +0100
Subject: [Matroska-devel] Re: [Matroska-general] IRC Meeting - Strategical
	Questions
In-Reply-To: <405AC3F3.9010006@matroska.org>
References: <405AC3F3.9010006@matroska.org>
Message-ID: <405AC646.1060609@free.fr>

I won't be home tonight. But I might be able to connect a bit later than 
that. I'll do my best.

Christian HJ Wiesner wrote:

> 
> Hi,
> 
> i'd like to invite you all to a strategical meeting about the future of 
> matroska, especially with respect to Gstreamer/matroska and TCME, the 
> planned video editor.
> 
> Meeting place is  irc.corecodec.com , #matroska , time for the meeting 
> is Friday, 19th March ( today ;-) ) , 22.00 h CET ( 21.00 h CMT ). We 
> are looking forward to your input and will welcome you on our channel.
> 
> Regards
> 
> Christian
> 
> _______________________________________________
> Matroska-general mailing list
> Matroska-general at lists.matroska.org
> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-general


From rbultje at ronald.bitfreak.net  Fri Mar 19 17:38:30 2004
From: rbultje at ronald.bitfreak.net (Ronald Bultje)
Date: Fri, 19 Mar 2004 17:38:30 +0100 (CET)
Subject: [Matroska-devel] Re: Re: [gst-devel] Gstreamer and matroska
	-theopensource answer to VideoforWindows/AVI and Quicktime/MOV ?
In-Reply-To: <c3dtlr$atu$1@sea.gmane.org>
Message-ID: <Pine.LNX.4.33.0403191737100.32017-100000@raq.textinfo.nl>

Hi,

On Thu, 18 Mar 2004, Paul Bryson wrote:
> "Ronald S. Bultje" wrote...
> > We don't. We let the app decide, we let randomness decide,
>
> What a very strange program.  "Behaviour differs on each run to keep things
> interesting".  A little like DirectShow, but apparently intentional.

Well, it's up to the app to decide itself or to let randomness decide.
Just, *we* do not decide.

> > Ogg is evenly preferred because it allows for storage of video and audio
>
> The only codec that I have ever seen in Ogg is Vorbis, although I understand
> that it actually supports a few other Xiph endorsed audio codecs.  Where is this
> Ogg Video file that you speak of?  (remembering of course that Ogg != OGM)

Tarkin might be in early alpha, but theora definately works. Try the
latest betas. We have decoder plugins in gst-0.8.0.

Ronald



From christian at matroska.org  Fri Mar 19 20:26:54 2004
From: christian at matroska.org (ChristianHJW)
Date: Fri, 19 Mar 2004 20:26:54 +0100
Subject: [Matroska-devel] Re: [gst-devel] Gstreamer and matroska - the
 opensource answer to VideoforWindows/AVI and Quicktime/MOV ?
In-Reply-To: <1079641977.2412.1.camel@shrek.bitfreak.net>
References: <40338455.3050905@matroska.org>
	<1079641977.2412.1.camel@shrek.bitfreak.net>
Message-ID: <405B497E.6040009@matroska.org>

Ronald S. Bultje wrote:
> GStreamer is not bound to a single container, nor does it need a
> preferred one. Users use individually preferred containers. If we would
> ever want to set automated preferences (planned for 0.9.x by me), I'd
> give any open format a higher preference than a closed one. Obviously,
> (example) Matroska would be preferred over (example) ASF. However, Ogg
> and Matroska would be evenly preferred. I don't want to bind to a single
> container because I don't see that as an obvious task for a media
> framework.

Playing devil's advocate :

Q : What does differentiate Gstreamer from mplayer or Xine ?

A : Gstreamer is a media framework, mplayer and Xine are merely playback 
apps


Q : Whats the advantage of a framework, compared to a playback app ?

A : a. Its easier to develop video and audio apps based on the 
framework, existing work can be reused, apps based on the framework can 
support any format where a plugin exists.
b. People can start making their own plugins, and have their own 
video/audio compression solutions based on the framework, and simply by 
plugin distribution everybody can use their stuff

While a. is a quite obvious advantage for the programmers, it doesnt 
really give the users an advantage performance wise. If you ask most 
desktop users if they know the difference between a player based on a 
framework like Quicktime, DirectShow or Gstreamer, and 'self-contained' 
players like VLC, Xine or mplayer, i bet less than 10% do know. The most 
important thing for them is that they get their stuff to play, thats it.

Speaking about b. , Quicktime, Video for Windows, DirectShow, Helix, all 
of them could be used by codec developers to release a codec for various 
platforms, and to make sure the files created can be played on a big 
number of PCs. 3ivX ( http://www.3ivx.com ) are a good example for that, 
they made a nice MPEG4 codec and are releasing it in 3 different 
versions, for 3 different frameworks :
- VfW / VCM
- Quicktime
- DirectShow ( only decoder AFAIK )
Ask them if they would be happy if they could standardize on a single 
framework, which would cover all major platforms.

I am well aware you guys dont get requests like that yet, but rest 
assured that the matroska team has at least one serious request per 
month from codec devlopers investigating if our container could be a 
proper way to base their codec on, and to ensure playback and creation 
on at least the 2 major platforms, Windows and Linux.

Gstreamer, but only after a win32 ( and later MacOSX ) port, could be an 
answer here, while right now we have to make clear to them that we could 
modify mkvmerge to mux their stuff into matroska, and its compiled for 
Linux, Windows and MacOSX, but the only matroska video editor we have is 
for Windows, and will handle only ( mostly ) tracks with VCM or ACM 
compatibility mode, similar to AVI, and thats it. For playback, mplayer 
and VLC would be the only viable x-platform options, means the guys have 
to release special builds of those players, for each platform and with 
their decoder included.

For the time being it seems that only Helix is a true x-platform 
multimedia framework, with a basic video editor and playback support on 
all platforms. Their stuff compiles on Windows, Linux, MacOSX and 
Solaris IIRC. But dont ask me if a codec developer would truely consider 
to convince their users to use Realplayer to play their stuff ;) ....

Christian



From steve.lhomme at free.fr  Sat Mar 20 12:12:17 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Sat, 20 Mar 2004 12:12:17 +0100
Subject: [Matroska-devel] Re: [Matroska-general] Re: [gst-devel] Gstreamer
 and matroska - the
 opensource answer to VideoforWindows/AVI and Quicktime/MOV ?
In-Reply-To: <405B497E.6040009@matroska.org>
References: <40338455.3050905@matroska.org>	<1079641977.2412.1.camel@shrek.bitfreak.net>
	<405B497E.6040009@matroska.org>
Message-ID: <405C2711.8070502@free.fr>

ChristianHJW wrote:

> Q : Whats the advantage of a framework, compared to a playback app ?
> 
> A : a. Its easier to develop video and audio apps based on the 
> framework, existing work can be reused, apps based on the framework can 
> support any format where a plugin exists.
> b. People can start making their own plugins, and have their own 
> video/audio compression solutions based on the framework, and simply by 
> plugin distribution everybody can use their stuff
> 
> While a. is a quite obvious advantage for the programmers, it doesnt 
> really give the users an advantage performance wise. If you ask most 
> desktop users if they know the difference between a player based on a 
> framework like Quicktime, DirectShow or Gstreamer, and 'self-contained' 
> players like VLC, Xine or mplayer, i bet less than 10% do know. The most 
> important thing for them is that they get their stuff to play, thats it.

This assumption depends on the "targeted audience". While it's very true 
among Windows users and probably Mac, it is less the case in the Unix 
world (things that just work are less common in the AV world ;). So it 
all depends on the audience. And GStreamer is clearly targeted at the 
Unix users.

> Gstreamer, but only after a win32 ( and later MacOSX ) port, could be an 
> answer here, while right now we have to make clear to them that we could 
> modify mkvmerge to mux their stuff into matroska, and its compiled for 
> Linux, Windows and MacOSX, but the only matroska video editor we have is 
> for Windows, and will handle only ( mostly ) tracks with VCM or ACM 
> compatibility mode, similar to AVI, and thats it. For playback, mplayer 
> and VLC would be the only viable x-platform options, means the guys have 
> to release special builds of those players, for each platform and with 
> their decoder included.

Because they don't share a cross-platform codec interface. (and this 
idea was considered stupid by the MPlayer ppl)

> For the time being it seems that only Helix is a true x-platform 
> multimedia framework, with a basic video editor and playback support on 
> all platforms. Their stuff compiles on Windows, Linux, MacOSX and 
> Solaris IIRC. But dont ask me if a codec developer would truely consider 
> to convince their users to use Realplayer to play their stuff ;) ....

It is very possible to make another player than RealPlyer based on 
Helix. Actually the Linux RealPlayer is not the same as the Windows one.




From R.S.Bultje at students.uu.nl  Sat Mar 20 20:38:58 2004
From: R.S.Bultje at students.uu.nl (Ronald S. Bultje)
Date: Sat, 20 Mar 2004 20:38:58 +0100
Subject: [Matroska-devel] Re: [gst-devel] Gstreamer and matroska -
	theopensource answer to VideoforWindows/AVI and Quicktime/MOV ?
In-Reply-To: <c3dpcm$3rg$1@sea.gmane.org>
References: <40338455.3050905@matroska.org>
	<1079641977.2412.1.camel@shrek.bitfreak.net>
	<c3dpcm$3rg$1@sea.gmane.org>
Message-ID: <1079811538.17277.29.camel@shrek.bitfreak.net>

On Fri, 2004-03-19 at 04:28, Paul Bryson wrote:
> I would prefer most things over Ogg because at this point it only stores Vorbis,
> and soon officially Theora.  Perhaps Matroska and NUT would be evenly preferred?
> Although, I imagine that (like every other program) GStreamer would only allow
> selecting a single initial default.  But what would you pick?  If you would
> indeed prefer an open format, then Matroska seems the obvious choice here.  It
> will store anything, and is already in 'wide spread' use.

We don't. We let the app decide, we let randomness decide, we let the
alphabet decide, I don't know. We won't have any official "GStreamer
file format" like Quicktime of VfW which is widely advertised on our
website, in each of our apps, etc. If we ever set "ranking icons" for
favoured or unfavoured formats, Matroska will get the same icon as other
container formats that meet our requirements similarly well. Etc.

Ogg is evenly preferred because it allows for storage of video and audio
using open container, video and audio codec. That's good enough. Note
that we don't have an Ogg muxer yet, though we're eagerly awaiting one.

Nut is currently vapourware (or under development; whichever you
prefer), see Michael's comments several months ago on ffmpeg-devel at .
Besides, we don't have a Nut muxer.

Ronald


From jcsston at wiesneronline.net  Sun Mar 21 09:22:19 2004
From: jcsston at wiesneronline.net (Jory)
Date: Sun, 21 Mar 2004 02:22:19 -0600
Subject: [Matroska-general] Re: [Matroska-devel] Re: [gst-devel]
	Gstreamerand matroska -theopensource answer to
	VideoforWindows/AVI and Quicktime/MOV ?
References: <40338455.3050905@matroska.org><1079641977.2412.1.camel@shrek.bitfreak.net><c3dpcm$3rg$1@sea.gmane.org>
	<1079811538.17277.29.camel@shrek.bitfreak.net>
Message-ID: <002f01c40f1d$ac882bd0$0200a8c0@jcsston>


----- Original Message -----
From: "Ronald S. Bultje" <R.S.Bultje at students.uu.nl>
To: "Paul Bryson" <paul at msn.com>
Cc: <matroska-devel at lists.matroska.org>;
<gstreamer-devel at lists.sourceforge.net>;
<matroska-general at lists.matroska.org>
Sent: Saturday, March 20, 2004 1:38 PM
Subject: [Matroska-general] Re: [Matroska-devel] Re: [gst-devel]
Gstreamerand matroska -theopensource answer to VideoforWindows/AVI and
Quicktime/MOV ?


> On Fri, 2004-03-19 at 04:28, Paul Bryson wrote:
> > I would prefer most things over Ogg because at this point it only stores
Vorbis,
> > and soon officially Theora.  Perhaps Matroska and NUT would be evenly
preferred?
> > Although, I imagine that (like every other program) GStreamer would only
allow
> > selecting a single initial default.  But what would you pick?  If you
would
> > indeed prefer an open format, then Matroska seems the obvious choice
here.  It
> > will store anything, and is already in 'wide spread' use.
>
> We don't. We let the app decide, we let randomness decide, we let the
> alphabet decide, I don't know. We won't have any official "GStreamer
> file format" like Quicktime of VfW which is widely advertised on our
> website, in each of our apps, etc. If we ever set "ranking icons" for
> favoured or unfavoured formats, Matroska will get the same icon as other
> container formats that meet our requirements similarly well. Etc.
>
> Ogg is evenly preferred because it allows for storage of video and audio
> using open container, video and audio codec. That's good enough. Note
> that we don't have an Ogg muxer yet, though we're eagerly awaiting one.
>
> Nut is currently vapourware (or under development; whichever you
> prefer), see Michael's comments several months ago on ffmpeg-devel at .
> Besides, we don't have a Nut muxer.
>
Nut is actually much better than Ogg, almost to the level of Matroska.

For Nut you have specs, a few tools for creation and playback of Nut files,
mplayer, spyder's muxer code, and Gabest's DShow demuxer.

While for Ogg you have no specs and the vapourware, magical OggFile class
which will solve all Ogg's problems...

Jory



From rbultje at ronald.bitfreak.net  Sun Mar 21 23:05:01 2004
From: rbultje at ronald.bitfreak.net (Ronald Bultje)
Date: Sun, 21 Mar 2004 23:05:01 +0100 (CET)
Subject: [Matroska-general] Re: [Matroska-devel] Re: [gst-devel]
	Gstreamerand
	matroska -theopensource answer to VideoforWindows/AVI and Quicktime/MOV
	?
In-Reply-To: <002f01c40f1d$ac882bd0$0200a8c0@jcsston>
Message-ID: <Pine.LNX.4.33.0403212303550.788-100000@raq.textinfo.nl>

Hi,

On Sun, 21 Mar 2004, Jory wrote:
> For Nut you have specs, a few tools for creation and playback of Nut files,
> mplayer, spyder's muxer code, and Gabest's DShow demuxer.

Nut's specs aren't final. Besides that, no single movie on *my* HD is Nut.
you know Eric Raymond's scratch and itch story, don't you?

> While for Ogg you have no specs and the vapourware, magical OggFile class
> which will solve all Ogg's problems...

Unfortunately (or not?), I do have Ogg files.

Ronald



From paul at msn.com  Mon Mar 22 04:53:26 2004
From: paul at msn.com (Paul Bryson)
Date: Sun, 21 Mar 2004 21:53:26 -0600
Subject: [Matroska-devel] Re: [Matroska-general] Re: Re:
	[gst-devel]Gstreamerandmatroska -theopensource answer to
	VideoforWindows/AVI and Quicktime/MOV?
References: <002f01c40f1d$ac882bd0$0200a8c0@jcsston>
	<Pine.LNX.4.33.0403212303550.788-100000@raq.textinfo.nl>
Message-ID: <c3lnuu$8ti$1@sea.gmane.org>

"Ronald Bultje" wrote...
> Unfortunately (or not?), I do have Ogg files.

With video?


Pamel





From paul at msn.com  Tue Mar 23 00:07:46 2004
From: paul at msn.com (Paul Bryson)
Date: Mon, 22 Mar 2004 17:07:46 -0600
Subject: [Matroska-devel] New CSS version selecting in CVS.
Message-ID: <c3nrjr$gqb$1@sea.gmane.org>

View and play with it here:
http://matroska.org/technical/specs/index.html

Also, added the new TrackOffset that I had mentioned earlier.  Perhaps it would
be more appropriate to call it TrackTimecodeOffset?
http://matroska.org/technical/specs/index.html#TrackOffset


Pamel





From steve.lhomme at free.fr  Tue Mar 23 09:48:15 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 23 Mar 2004 09:48:15 +0100
Subject: [Matroska-devel] New CSS version selecting in CVS.
In-Reply-To: <c3nrjr$gqb$1@sea.gmane.org>
References: <c3nrjr$gqb$1@sea.gmane.org>
Message-ID: <405FF9CF.7070108@free.fr>

Paul Bryson wrote:

 > Also, added the new TrackOffset that I had mentioned earlier. 
Perhaps it would
 > be more appropriate to call it TrackTimecodeOffset?
 > http://matroska.org/technical/specs/index.html#TrackOffset


Both are OK with me.

PS : The reply used to reply to the ML IIRC, why did it change ?


From paul at msn.com  Tue Mar 23 21:41:15 2004
From: paul at msn.com (Paul Bryson)
Date: Tue, 23 Mar 2004 14:41:15 -0600
Subject: [Matroska-devel] Re: Tag names
References: <40532BBD.8060909@home.nl><c2vl69$l03$1@sea.gmane.org>	<4054B190.7050008@home.nl><c33ma6$ndm$1@sea.gmane.org>	<4055D0F2.7020907@home.nl><c34pmu$k02$1@sea.gmane.org>	<4056F5BF.3030605@home.nl><c3a3h2$j96$1@sea.gmane.org>
	<4058CDBF.7020905@home.nl>
Message-ID: <c3q7cu$f0q$1@sea.gmane.org>

I forgot to reply to this message...

"Age Bosma" wrote...
> Too bad :-(
> In that cse I would prefer BEATSPM to stay consistent with the FRAMESPS
> and BITSPS.

Changed to BEATSPM.

> INVOLVED_PERSON would be a good place to store it but that name isn't
> very descriptive in this case. We could just change that on to FEATURING
> but I don't know if it would couse problems in other cases.

I think the key here would be to find out what everyone is using.

> You got a point, my Enlish isn't perfect but wouldn't DESIGNATED_PRODUCT
> be even better? If no, INTENDED_PRODUCT is just fine.

Changed to INTENDED_PRODUCT.

> The reason I mentioned it was because it doesn't happen a lot that only
> one instrument is used in a song. Therefor it should be made clear it's
> possible (by an example again as well) to use the field multiple time if
> that's the case in the first place.

Hopefully having several examples to cover 99% of cases should make this clear.

> >>- DATE_RELEASE_ORIGINAL -> DATE_ORIGINAL_RELEASE
> >
> > Is that really better with DATE_RELEASE just above it?  To my eyes it looks
> > better this way, but I am not sure.  I asked in IRC and one person responded
> > that they prefer DRO.  "don't you like french word order?"
>
> I prefer sticking to the main sequence in which the word ORIGINAL_ is
> used in the other fields. In this case you (probably) want to keep DATE_
> in front otherwise I would have changed it to ORIGINAL_RELEASE_DATE.
> And no, I don't like french word order (no offence intended). ;-)

I don't have time to think this one over, but you may be right.  I'll get to it
later.

> It's not the same as the Vorbis PERFORMER tag as you look at the
> descriptions closely, this field should be placed with CONDUCTOR like in
> my reference. Also for ID3 and APE ARTIST are the only fields that come
> close enough to the LEAD_PERFORMER Matroska field.
>  From a e.g. a jazz point of view you may speak about LEAD_PERFORMER
> together with BAND but everyone will know what you mean if you use
> ARTIST and BAND in this case as well. This makes it possible to use the
> ARTIST field for e.g. just "Dire Straits" or "Slipknot" as well and
> therefor being fully compatible with the other tag types. Using
> LEAD_PERFORMER in a "Dire Straits" or "Slipknot" context makes much less
> sense.

I want to know what is used in fb2k before deciding this one.  The use of
different terms that overlap a lot has made this a confusing point.

> It's still basicly the same imo. Did you read my other extra post about
> this? If we include a new level for all "original" info this would rule
> out confusion and clean up a lot of fields we have at the moment.

I agree.  We need to make a list of items to go here.  In my understanding, it
looks like this would only be used for cases where someone has done a remix of a
song, or a remake of a movie.  Then you use "ORIGINAL_" to store data about the
original song/movie.

> >>- INVOLVED_PERSON -> CREDITS
> >>   Not sure again if this would be wise to change though.
> >
> > I think that CREDITS sounds better and would probably be more intuitive, but
it
> > would probably induce people to store a list in a single tag instead of
multiple
> > tags.
>
> Drop it completely and add FEATURING like mentioned earlier in this mail.

Those sound like two different items.  FEATURING would be someone you see/hear.
INVOLVED_PERSON could be someone like a gaffer or a makeup artist.

> >>- EDITION -> VERSION
> >
> > For DVDs, this is always referred to as the Edition.  For instance, I have
DVDs
> > that are "Directors Cut", "Collector's", "Ultimate", and various other
editions.
> > Is this done differently with CDs?
>
> If it comes to songs I think VERSION would be more suitable. Like "Fear
> Factory - New Breed (Spoetnik Mix)" or "Linkin Park - Dedicated (Demo
> 1999)". They talk about different versions of the song. If you look
> strictly at the definition of both words VERSION would be more suitable
> in both cases, dvd and audio.
> Maybe we should think about a more general name for this instead.

I am open to ideas.

> That would be a duplicate entry. I think only the ratio will be fine
> because most people using terms like "widescreen" or "fullscreen" will
> probably know what they are talking about and therefor know the ratio as
> well. If we give people an extra option they will most likely leave out
> the actual ratio which imo will describe it more accurately and will
> rule out any mistakes.

I'm not sure I follow you, what fields do you want?

> > How would you store this DVD of mine?
> > Bruce Campbell vs. Army Of Darkness
> > The Director' Cut
> > Official Bootleg Edition
> > Widescreen Presentation
> >
> > Photos available here:
> > http://www.jkfanclub.com:81/matroska/Projects/Photos/
> > And yes, the DVD actually says "DVD-R4x Not Really Recordable 96 MIN" and
> > "Un-Recordable 1x-4x Compatible"
>
> I'll work on a sample tomorrow, the site with the photo's is down and
> it's getting late. ;-)

The site should be working.  Perhaps your firewall doesn't like port 81?

I look forward to seeing your sample.


Pamel





From R.S.Bultje at students.uu.nl  Tue Mar 23 20:48:24 2004
From: R.S.Bultje at students.uu.nl (Ronald S. Bultje)
Date: Tue, 23 Mar 2004 20:48:24 +0100
Subject: [Matroska-devel] Re: [Matroska-general] Re: Re:
	[gst-devel]Gstreamerandmatroska -theopensource answer to
	VideoforWindows/AVI and Quicktime/MOV?
In-Reply-To: <c3lnuu$8ti$1@sea.gmane.org>
References: <002f01c40f1d$ac882bd0$0200a8c0@jcsston>
	<Pine.LNX.4.33.0403212303550.788-100000@raq.textinfo.nl>
	<c3lnuu$8ti$1@sea.gmane.org>
Message-ID: <1080071304.14014.2.camel@shrek.bitfreak.net>

On Mon, 2004-03-22 at 04:53, Paul Bryson wrote:
> "Ronald Bultje" wrote...
> > Unfortunately (or not?), I do have Ogg files.
> With video?

No. Does that matter for the Ogg model?

Ronald



From paul at msn.com  Tue Mar 30 19:55:58 2004
From: paul at msn.com (Paul Bryson)
Date: Tue, 30 Mar 2004 11:55:58 -0600
Subject: [Matroska-devel] Ogg and Vorbis/Speex/FLAC directshow filters
Message-ID: <c4ccan$a6l$1@sea.gmane.org>

Congratulations on making a free set of handy DirectShow filters.  I was just
writing to ask if you would add support for currently existing DirectShow pins
so that people may more easily use these filters with existing filters.  Please
look here for more information.

http://corecodec.org/projects/coreflac
http://corecodec.org/projects/corevorbis
http://www.speex.org/download/speexDS_setup.zip
http://forum.doom9.org/showthread.php?s=&threadid=58680 <-- OGM...

Also, if you would like some more input on your filters, try posting here.
http://forum.doom9.org/showthread.php?s=&postid=465443
If they work with existing filters, people will be more than happy to try them
out.


Pamel





From paul at msn.com  Wed Mar 31 07:53:51 2004
From: paul at msn.com (Paul Bryson)
Date: Tue, 30 Mar 2004 23:53:51 -0600
Subject: [Matroska-devel] Re: Ogg and Vorbis/Speex/FLAC directshow filters
References: <c4ccan$a6l$1@sea.gmane.org>
Message-ID: <c4dmck$u5u$1@sea.gmane.org>

I was also talking with the CoreVorbis fellows just a few days ago about using a
standard set of GUIDs.  Except that it was more to do with a standard way to
generate GUIDs.  This was for consideration from the Matroska project as
Matroska uses a human readable codec ID.  A list of the current IDs is available
here:
http://matroska.org/technical/specs/codecid/index.html

Here is what has been more or less decided. GUIDs are 128bit (16byte).  So, it
was decided to use the first byte as an ASCII character indicating the pin type
(Audio, Video, etc).  Then you make an MD5 checksum of the CodecID and store the
first 15 bytes in the remaining 15 bytes of the GUID.  In this way you know
immediately what type of connection it is.  Also, source filters do not need to
be updated to know what GUID should be used for a specific codec as they could
generate them on the fly.  Known GUIDs would stay the same.  If a en/decoder
filter could be updated, it is recommended to update it to also connect to the
pin type using the MD5 checksum.


Pamel

----- Original Message ----- 
From: "illiminable" <ogg at illiminable.com>
To: "Paul Bryson" <paul at msn.com>
Sent: Tuesday, March 30, 2004 6:17 PM
Subject: Re: Ogg and Vorbis/Speex/FLAC directshow filters


Hi there... i've been talking to the coreVorbis guys recently... And we were
takling about using a standard set of GUIDS so that they can talk...

At the moment i deliberately chose different ones to a) avoid other filter
sets interfering while they are in testing and b) to stop my filters messing
with anyone elses.

It is my aim to be as compatible as possible eventually... but theres some
intensive testing that needs to be done before letting the different filters
all start talking to each otehr.

Thanks for the feedback,

Zen.