From alex at fsn.hu  Tue May  4 11:55:50 2004
From: alex at fsn.hu (Alex Beregszaszi)
Date: Tue, 4 May 2004 11:55:50 +0200
Subject: [Matroska-devel] LinuxTAG 2004: Free Video Booth
Message-ID: <20040504115550.1a40d5eb@caprice.artificis.hu>

Hi,

"Diego Biurrun and myself from MPlayer are thinking about organizing
this
year a big common booth among video related open source projects."

The booth is just organized, some questions are still open.

1, If you want to participate and would stay more than a day, please
reply if you need accomodation. The event offers sleeping place, but you
need to get a sleeping bag tho. Breakfast is available also for
3euro/day.

2, We need to get a projector/beamer.

3, What presentations would you like to do?

Please reply ASAP!

-- 
Alex Beregszaszi 			e-mail: alex at fsn.hu
Free Software Network			cell: +36 70 3144424


From steve.lhomme at free.fr  Tue May  4 12:58:41 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 04 May 2004 12:58:41 +0200
Subject: [Matroska-devel] LinuxTAG 2004: Free Video Booth
In-Reply-To: <20040504115550.1a40d5eb@caprice.artificis.hu>
References: <20040504115550.1a40d5eb@caprice.artificis.hu>
Message-ID: <40977761.604@free.fr>

I'd really like to go ! But not alone from Matroska :( (otherwise it's 
only people I don't know)

Alex Beregszaszi wrote:

> Hi,
> 
> "Diego Biurrun and myself from MPlayer are thinking about organizing
> this
> year a big common booth among video related open source projects."
> 
> The booth is just organized, some questions are still open.
> 
> 1, If you want to participate and would stay more than a day, please
> reply if you need accomodation. The event offers sleeping place, but you
> need to get a sleeping bag tho. Breakfast is available also for
> 3euro/day.
> 
> 2, We need to get a projector/beamer.
> 
> 3, What presentations would you like to do?
> 
> Please reply ASAP!
> 


From devel at vegardw.com  Thu May  6 17:28:38 2004
From: devel at vegardw.com (=?iso-8859-15?Q?Vegard_W=E6rp?=)
Date: Thu, 06 May 2004 17:28:38 +0200
Subject: [Matroska-devel] Patches to make libebml and libmatroska compile on
	BeOS
Message-ID: <opr7k3x0b87fddqb@r2d2.mshome.net>

Hi all,

As libebml an libmatroska 0.7.0 wouldnt compile out of the box on BeOS  
when I tried, I thought I'd try to make i compile, and came out with a  
quick and dirty patch consisting mostly of some #ifdefs.

The patches, which is against 0.7.0, are at:
http://home.no.net/vegardwa/libebml.diff for libebml,
and http://home.no.net/vegardwa/libmatroska.diff for libmatroska


Changes to libebml:
  - There was no Makefile for BeOS, so I copied the Linux one and changed  
it a bit.
  - ebml/c/libebml_t.h: BeOS has a system header that defines int16, int32,  
uintXX etc, changed to use that when compiling on BeOS
  - BeOS 5.0 doesnt seem to have stringstream in <sstream>, which is used  
in the lib. But it has strstream in <strstream> however. I dont know what  
the difference between those two is, but by changing it the lib compiled  
cleanly on BeOS.


Changes to libmatroska:
- Some changes in the Makefile
- test/mux/test8.cpp: BeOS doesnt have wprintf, changed it use printf like  
for apple/cygwin


Todo:
  - The BeOS makefiles for both libs need a makeover, I just changed what I  
needed to make it compile.
  - I havent tested that the libs really work yet, just that they compile.
  - I've only tried compiling on BeOS 5 Personal Edition, havent tested on  
other versions, like Zeta yet.


It would be nice if someone has the time to review these patches and point  
out what needs to be changed for the patches to be incorporated into the  
sources. I hope this is the right mailing list for it. Matroska seems like  
a interesting project, and better BeOS/OpenBeOS support for the format  
would be nice. Making the libs compile one BeOS doesnt give support  
automatically, but it's a step in the right direction.


Regards,
Vegard W?rp
-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/



From steve.lhomme at free.fr  Thu May  6 21:04:53 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Thu, 06 May 2004 21:04:53 +0200
Subject: [Matroska-devel] Patches to make libebml and libmatroska compile
	on	BeOS
In-Reply-To: <opr7k3x0b87fddqb@r2d2.mshome.net>
References: <opr7k3x0b87fddqb@r2d2.mshome.net>
Message-ID: <409A8C55.9030309@free.fr>

Vegard W?rp wrote:
> Hi all,
> 
> As libebml an libmatroska 0.7.0 wouldnt compile out of the box on BeOS  
> when I tried, I thought I'd try to make i compile, and came out with a  
> quick and dirty patch consisting mostly of some #ifdefs.
> 
> The patches, which is against 0.7.0, are at:
> http://home.no.net/vegardwa/libebml.diff for libebml,
> and http://home.no.net/vegardwa/libmatroska.diff for libmatroska
> 
> 
> Changes to libebml:
>  - There was no Makefile for BeOS, so I copied the Linux one and 
> changed  it a bit.

What was changed ? Maybe it's possible to merge the 2 in one ?
Othewise the other changes seem to be OK.

> Changes to libmatroska:
> - Some changes in the Makefile

Same question, but :
INCLUDE=-I${SRC_DIR} -I../../ -I../../../libebm/

Either libebm is not needed or there is a typo.

> - test/mux/test8.cpp: BeOS doesnt have wprintf, changed it use printf 
> like  for apple/cygwin
> 
> 
> Todo:
>  - The BeOS makefiles for both libs need a makeover, I just changed what 
> I  needed to make it compile.
>  - I havent tested that the libs really work yet, just that they compile.

Please let us know.

>  - I've only tried compiling on BeOS 5 Personal Edition, havent tested 
> on  other versions, like Zeta yet.
> 
> 
> It would be nice if someone has the time to review these patches and 
> point  out what needs to be changed for the patches to be incorporated 
> into the  sources. I hope this is the right mailing list for it. 
> Matroska seems like  a interesting project, and better BeOS/OpenBeOS 
> support for the format  would be nice. Making the libs compile one BeOS 
> doesnt give support  automatically, but it's a step in the right direction.

Of course ! We worked with the people of OBOS at the beggining of our 
development but lost focus... BTW, VLC works under BeOS too and has 
matroska support. Could you see if that's correct ?


From devel at vegardw.com  Thu May  6 22:21:13 2004
From: devel at vegardw.com (=?iso-8859-15?Q?Vegard_W=E6rp?=)
Date: Thu, 06 May 2004 22:21:13 +0200
Subject: [Matroska-devel] Re: Patches to make libebml and libmatroska
	compile on	BeOS
References: <opr7k3x0b87fddqb@r2d2.mshome.net> <409A8C55.9030309@free.fr>
Message-ID: <opr7lhhnr27fddqb@r2d2.mshome.net>

On Thu, 06 May 2004 21:04:53 +0200, Steve Lhomme <steve.lhomme at free.fr>  
wrote:

> Vegard W?rp wrote:
>>  - There was no Makefile for BeOS, so I copied the Linux one and  
>> changed  it a bit.
>
> What was changed ? Maybe it's possible to merge the 2 in one ?
> Othewise the other changes seem to be OK.

the install path is different in BeOS at least, thats the first ting that  
I can think of, could be more. I'll look more into it

>
>> Changes to libmatroska:
>> - Some changes in the Makefile
>
> Same question, but :
> INCLUDE=-I${SRC_DIR} -I../../ -I../../../libebm/
>
> Either libebm is not needed or there is a typo.

Typo, changed something before I made the diff, without compiling to  
check, saw it after I uploaded the file :) I'll try fix up both make files  
and make a new patch

>>  - I havent tested that the libs really work yet, just that they  
>> compile.
>
> Please let us know.

I managed to get mkvinfo from mkvtoolnix to compile, and that seemed to  
work on my test files. I haven't gotten the rest of mkvtoolnix to compile  
yet, so I dont know about the rest (muxing/demuxing). My coding skills are  
pretty limited, especially when it comes to media stuff, not to mention  
that its about two years since I coded something that was longer than a  
couple of hundred lines. So it will take some time before I get mkvtoolnix  
ported. :)

>> Matroska seems like  a interesting project, and better BeOS/OpenBeOS  
>> support for the format  would be nice. Making the libs compile one BeOS  
>> doesnt give support  automatically, but it's a step in the right  
>> direction.
>
> Of course ! We worked with the people of OBOS at the beggining of our  
> development but lost focus... BTW, VLC works under BeOS too and has  
> matroska support. Could you see if that's correct ?

Yup, I'll check it out. I think the BeOS VLC port is pretty complete  
feature-wise, but I'll test it to be sure.


   --Vegard
-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/



From moritz at bunkus.org  Thu May  6 22:30:21 2004
From: moritz at bunkus.org (Moritz Bunkus)
Date: Thu, 6 May 2004 22:30:21 +0200
Subject: [Matroska-devel] Re: Patches to make libebml and libmatroska
	compile on	BeOS
In-Reply-To: <opr7lhhnr27fddqb@r2d2.mshome.net>
References: <opr7k3x0b87fddqb@r2d2.mshome.net> <409A8C55.9030309@free.fr>
	<opr7lhhnr27fddqb@r2d2.mshome.net>
Message-ID: <20040506203021.GL22839@bunkus.org>

Hi,

> I managed to get mkvinfo from mkvtoolnix to compile, and that seemed to  
> work on my test files. I haven't gotten the rest of mkvtoolnix to compile  
> yet, so I dont know about the rest (muxing/demuxing). My coding skills are  
> pretty limited, especially when it comes to media stuff, not to mention  
> that its about two years since I coded something that was longer than a  
> couple of hundred lines. So it will take some time before I get mkvtoolnix  
> ported. :)

Don't hesitate to post compiler errors here. I'm sure I can help one way
or another. One thing you probably have to do is add some #defines to
src/common/os.h so that SYS_UNIX gets defined for BeOS (I'm assuming
that BeOS is more like Unix than Windows).

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 devel at vegardw.com  Fri May  7 11:00:49 2004
From: devel at vegardw.com (=?iso-8859-15?Q?Vegard_W=E6rp?=)
Date: Fri, 07 May 2004 11:00:49 +0200
Subject: [Matroska-devel] Re: Patches to make libebml and libmatroska
	compile on	BeOS
References: <opr7k3x0b87fddqb@r2d2.mshome.net> <409A8C55.9030309@free.fr>
	<opr7lhhnr27fddqb@r2d2.mshome.net>
Message-ID: <opr7mgnnku7fddqb@r2d2.mshome.net>


>> BTW, VLC works under BeOS too and has matroska support. Could you see  
>> if that's correct ?
>
> Yup, I'll check it out. I think the BeOS VLC port is pretty complete  
> feature-wise, but I'll test it to be sure.
>

Tried the latest VLC for BeOS with  
Matrix.Reloaded.Trailer-640x346-XviD-1.0beta2-HE_AAC_subtitled.mkv and  
mewmew-vorbis-ssa.mkv from dl.matroska.org as well as a file I transmuxed  
 from from avi (XviD/MP3) They all worked fine except for the matrix  
trailer, which crashed VLC. But it looks like something the audio decoding  
crashed it. Both video and subtitles continued playing without problems if  
I didn't click "OK" in the crash alert. Maybe I'll compile VLC with  
debugging and see if I can find out where it's crashing. So from my very  
limited testing it seems like the BeOS port is more or less on par with  
the other VLC ports when it comes to matroska.


   --Vegard



From steve.lhomme at free.fr  Fri May  7 11:07:16 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Fri, 07 May 2004 11:07:16 +0200
Subject: [Matroska-devel] Re: Patches to make libebml and libmatroska
	compile on	BeOS
In-Reply-To: <opr7mgnnku7fddqb@r2d2.mshome.net>
References: <opr7k3x0b87fddqb@r2d2.mshome.net>
	<409A8C55.9030309@free.fr>	<opr7lhhnr27fddqb@r2d2.mshome.net>
	<opr7mgnnku7fddqb@r2d2.mshome.net>
Message-ID: <409B51C4.3040902@free.fr>

Vegard W?rp wrote:

> 
>>> BTW, VLC works under BeOS too and has matroska support. Could you 
>>> see  if that's correct ?
>>
>>
>> Yup, I'll check it out. I think the BeOS VLC port is pretty complete  
>> feature-wise, but I'll test it to be sure.
>>
> 
> Tried the latest VLC for BeOS with  
> Matrix.Reloaded.Trailer-640x346-XviD-1.0beta2-HE_AAC_subtitled.mkv and  
> mewmew-vorbis-ssa.mkv from dl.matroska.org as well as a file I 
> transmuxed  from from avi (XviD/MP3) They all worked fine except for the 
> matrix  trailer, which crashed VLC. But it looks like something the 
> audio decoding  crashed it. Both video and subtitles continued playing 
> without problems if  I didn't click "OK" in the crash alert. Maybe I'll 
> compile VLC with  debugging and see if I can find out where it's 
> crashing. So from my very  limited testing it seems like the BeOS port 
> is more or less on par with  the other VLC ports when it comes to matroska.

Thanx for the info ! It's good to know :)


From devel at vegardw.com  Mon May 10 18:26:11 2004
From: devel at vegardw.com (=?ISO-8859-1?Q?Vegard_W=E6rp?=)
Date: Mon, 10 May 2004 18:26:11 +0200
Subject: [Matroska-devel] Makefile question
Message-ID: <PM0003DA1477A9D893@yoda.unknown.dom>

Havent had time the last days, but today I thought I'd clean up the BeOS
makefiles and  put up a new BeOS patch.

The only thing that has to be edited in the linux makefile to make it
compile is the install path. This is the same for both libebml and
libmatroska. If there is an easy way to check which system you're
running on from the makefile, (there probably is, but I'm not that good
at makefiles) there wouldnt be any need for a separate makefile at all.

Would that be a better solution, or would sepearate makefiles be
preferred?

  --Vegard



From moritz at bunkus.org  Mon May 10 18:40:34 2004
From: moritz at bunkus.org (Moritz Bunkus)
Date: Mon, 10 May 2004 18:40:34 +0200
Subject: [Matroska-devel] Makefile question
In-Reply-To: <PM0003DA1477A9D893@yoda.unknown.dom>
References: <PM0003DA1477A9D893@yoda.unknown.dom>
Message-ID: <20040510164034.GZ22839@bunkus.org>

Hi,

Traditionally there's the Unix command 'uname' which gives you the
system type if invoked with -s:

0 mosu at tahiri:~$ uname -s
Linux

You can check for that with the usual Makefile tools, e.g.

ifeq (BeOS,$(shell uname -s))
# do something BeOS specific
else
# do something more general
endif

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 devel at vegardw.com  Mon May 10 19:39:35 2004
From: devel at vegardw.com (=?ISO-8859-1?Q?Vegard_W=E6rp?=)
Date: Mon, 10 May 2004 19:39:35 +0200
Subject: [Matroska-devel] BeOS patches
Message-ID: <PM0003DA157E2647A9@yoda.unknown.dom>

New BeOS patches for libebml and libmatroska, using the linux makefile
instead of a separate beos make makefile. Both diffs are against the
0.7.0 source, not cvs.

http://home.no.net/vegardwa/libebml_2004_05_10.diff
and
http://home.no.net/vegardwa/libmatroska_2004_05_10.diff

And now, onto getting mkvtoolnix to compile on BeOS :)

  --Vegard



From steve.lhomme at free.fr  Tue May 11 21:47:53 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 11 May 2004 21:47:53 +0200
Subject: [Matroska-devel] BeOS patches
In-Reply-To: <PM0003DA157E2647A9@yoda.unknown.dom>
References: <PM0003DA157E2647A9@yoda.unknown.dom>
Message-ID: <40A12DE9.5060908@free.fr>

Vegard W?rp wrote:

> New BeOS patches for libebml and libmatroska, using the linux makefile
> instead of a separate beos make makefile. Both diffs are against the
> 0.7.0 source, not cvs.
> 
> http://home.no.net/vegardwa/libebml_2004_05_10.diff
> and
> http://home.no.net/vegardwa/libmatroska_2004_05_10.diff

Error 404 on both :(


From devel at vegardw.com  Tue May 11 22:04:48 2004
From: devel at vegardw.com (=?iso-8859-15?Q?Vegard_W=E6rp?=)
Date: Tue, 11 May 2004 22:04:48 +0200
Subject: [Matroska-devel] BeOS patches
References: <PM0003DA157E2647A9@yoda.unknown.dom> <40A12DE9.5060908@free.fr>
Message-ID: <opr7up2auq7fddqb@yoda.mshome.net>

Steve Lhomme wrote:
> Vegard W?rp wrote:
>>  http://home.no.net/vegardwa/libebml_2004_05_10.diff
>> and
>> http://home.no.net/vegardwa/libmatroska_2004_05_10.diff
>
> Error 404 on both :(
>


Oops, typo...
the urls should be
http://home.no.net/vegardwa/libebml_2004-05-10.diff
and
http://home.no.net/vegardwa/libmatroska_2004-05-10.diff

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/



From steve.lhomme at free.fr  Tue May 11 23:39:30 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Tue, 11 May 2004 23:39:30 +0200
Subject: [Matroska-devel] BeOS patches
In-Reply-To: <opr7up2auq7fddqb@yoda.mshome.net>
References: <PM0003DA157E2647A9@yoda.unknown.dom> <40A12DE9.5060908@free.fr>
	<opr7up2auq7fddqb@yoda.mshome.net>
Message-ID: <40A14812.1000101@free.fr>

Vegard W?rp wrote:
> Steve Lhomme wrote:
> 
>> Vegard W?rp wrote:
>>
>>>  http://home.no.net/vegardwa/libebml_2004_05_10.diff
>>> and
>>> http://home.no.net/vegardwa/libmatroska_2004_05_10.diff
>>
>>
>> Error 404 on both :(
>>
> 
> 
> Oops, typo...
> the urls should be
> http://home.no.net/vegardwa/libebml_2004-05-10.diff
> and
> http://home.no.net/vegardwa/libmatroska_2004-05-10.diff

It's applied now, thanks to Mosu...


From moritz at bunkus.org  Tue May 11 22:35:01 2004
From: moritz at bunkus.org (Moritz Bunkus)
Date: Tue, 11 May 2004 22:35:01 +0200
Subject: [Matroska-devel] BeOS patches
In-Reply-To: <opr7up2auq7fddqb@yoda.mshome.net>
References: <PM0003DA157E2647A9@yoda.unknown.dom> <40A12DE9.5060908@free.fr>
	<opr7up2auq7fddqb@yoda.mshome.net>
Message-ID: <20040511203501.GA22839@bunkus.org>

Hi,

applied, thanks.

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  Thu May 13 11:52:59 2004
From: paul at msn.com (Paul Bryson)
Date: Thu, 13 May 2004 04:52:59 -0500
Subject: [Matroska-devel] Re: Re: Tag names
References: <40532BBD.8060909@home.nl> <c2vl69$l03$1@sea.gmane.org>
	<4054B190.7050008@home.nl>
Message-ID: <c7vghk$vu9$1@sea.gmane.org>

"Age Bosma" wrote...
> Paul Bryson wrote:
>> Have you had any free time to work on this?  There are some ideas I would
>> like to kick around.
>
>Unfortunately I have to say no again. I did however post a new message
>on the Matroska mailing list and didn't get a reply yet.
>
>What ideas did you have in mind?

One of the devs is working on a perl script that queries tvtome.com for tv show
information.  It then places this info into an XML tag file that can be imported
into MKVMerge to be placed in a Matroska file.  Doing this, we quickly noticed
that there weren't any tags defined to store certain pieces of information.  For
instance:
http://www.tvtome.com/tvtome/servlet/GuidePageServlet/showid-3866/epid-85396/

Where do you store the Episode Number, Production Code, and Synopsis?  Also,
when you list an actor, how do you say the character that they played?  A quick
assigning produced this:

<Name>SET_TITLE</Name>
<String>Season 1</String>

<Name>SERIES</Name>
<String>24</String>

<Name>TITLE</Name>
<String>Episode 1</String>

<Name>SUBTITLE</Name>
<String>12:00 A.M.-1:00 A.M.</String>

<Name>DATE_RELEASE</Name>
<String>November 6, 2001</String>

<Name>WRITER</Name>
<String>Robert Cochran</String>

<Name>DIRECTOR</Name>
<String>Stephen Hopkins</String>

<Name>INVOLVED_PERSON</Name>
<String>Mia Kirshner</String>

<Name>SYNOPSIS</Name>
<String>Jack Bauer, an agent for the CIA...</String>

I don't think the TITLE and SUBTITLE are being used correctly for this right
now.  I really think the Episode number could be stored using current tags, but
I'm not sure how at the moment.  (possibly SET_PART?)  I am pretty sure that a
PRODUCTION_CODE needs to be added to the Identifiers section.  For the Character
being played, it should be easy to create a nested tag to the INVOLVED_PERSON
tag, but it needs a name.  The two that I could think of are ROLE and CHARACTER.
The word 'role' is very specific in its meaning, leaving little possibility to
get it wrong.  However, the word 'character' may fit better, even though it can
have many possible definitions that could confuse.  I am guessing CHARACTER.
What do you think?

>This was the one based in the gathered info from the foobar thread:
>-----------------------------------------------------------------------
>If MEDIA_PART can be used to store disc info, I suggest we add this
>example to the description of this tag.
>Because there can be other situations besides the number of discs, e.g.
>a video tape box set, etc., we can't change this filed name to just DISC
>imo.

Done.

>Should we add CUESHEET and LOGFILE? Although I don't like the idea of
>storing a complete file into a tag field, it has it's advantages.
>Personally I prefer a URI to the file in those fields but it's not being
>used this way. (we could allow both? :-S)

It won't go in the Matroska tags as Matroska has a specific way to store files
in it and define what they are.  In fact you can make tags for the files.

>SUBALBUM should be added.

Done.

>There's already a RATING field but with it's current description, does
>it fit in the context of the discussion?

The rating system that is referred to here is specifically in regards to
internet webpage contents.  However, the rules used by it are perfectly
applicable to everything that we need so far. It offers a standardized system to
describe language and image.

>Something in the line of ALBUM_ARTIST should be added but if we add it
>like this I think we should change LEAD_PERFORMER to ARTIST like I
>suggested before as well. For a consistency point of view it would
>cause confusing when we add ALBUM_ARTIST if there isn't a normal ARTIST
>field in the first place. We could also change it to
>ALBUM_LEAD_PERFORMER but imo LEAD_PERFORMER doesn't make much sense in
>the first place (check my reference to see what I mean).

Except that 'performer' makes much more sense in terms of actors than 'artist'
does.  An actor can be referred to as an artist, but it is uncommon.  But it
needs to be given further consideration.

>We should make clear in the description if we recommend SET_PART,
>TOTAL_SET_PART, MEDIA_PART and TOTAL_MEDIA_PART to be padded with
>zero's. In the decision I came to the conclusion we shouldn't use
>padding but I don't know what you think of that.

Any decent tag display program SHOULD be able to handle this for sorting
purposes.  I don't think there is any reason to define the padding used here.

>After that guruboolez posted an important reply in the foorbar thread
>about classical music. He's got some interesting points which should be
>dealt with imo.

Yes, the points brought up by guruboolez are a bit problematic.

>I'll just list his stuff one by one:
>- COMPOSITION
>Should be added or maybe even a sublevel should be created to fit in all
>the classical fields stuff.

I honestly don't know that much about organizational and linguistic structure
within classical music.  But couldn't the Composition name be stored in a tag
that already exists in the Titles section?  What is particular about it that
makes it not fit in any of those?  Would it be wrong to store the composition's
name in TITLE and the composition's part name in SUBTITLE?

>- COMPOSITION PART
>I do however don't like the idea to use it the way he does. E.g.
>COMPOSITION PART1 and COMPOSITION PART2 as field names. Is there already
>a way to use the same field multiple more than once?

For storing the number of the part, I would just add COMPOSITION_PART and
TOTAL_COMPOSITION_PARTS.  For each item, name the Composition, Composition part,
and the number.

>- COMPOSITION DATE
>DATE_COMPOSITION could be added, as far as I can see there isn't an
>alternative yet.

I added DATE_COMPOSITION.  However, I would like to use this field to also
describe when a script for a movie was made.  Is there a more generic name that
could be used?

>- COMPOSITION DESCRIPTION
>This one is kinda like the COMMENTS field...

Yes.  If he wants to describe the story in an opera, then he can use the new
SYNOPSIS tag.

>- OPUS and OPUSNUMBER
>I'm not sure how to deal with OPUS and OPUSNUMBER.

Pronunciation: ps, chiefly British ?p-
Function: noun
Inflected Form(s): plural opera \pr, ?p-\; also opuses
Etymology: Latin oper- opus -- more at OPERATE
: WORK: as a : a musical composition or set of compositions usually numbered in
the order of its issue -- abbr. op

I have no idea what those are used for or how they are used.  Perhaps this would
be something else that would go under the Identifiers section?

>- RECORDING DATE and RECORDING PLACE
>Are included already: DATE_RECORDING and RECORD_LOCATION

Yep.

>- MAIN PERFORMER
>Should the same as the current LEAD_PERFORMER (or ARTIST ;-))

Yep.

>- PERIOD and NATION
>Hmmm... eh, why not add them?

Added PERIOD and COMPOSITION_LOCATION.

>As for a comment Jasper made, DISCTITLE is a good one although to fit in
>with the current Matroska fields maybe we should change it to
>MADIA_PART_TITLE? ...and while we're at it add SET_PART_TITLE as well?
>
>Like GO2Null mentioned, I still agree on adding the FEATURING field as
>well. :-D

I will explain these a later when I am alert enough.  I need sleep now.


Pamel


begin 666 primarystress.gif
M1TE&.#EA! `,`/<```````$!`0("`@,#`P0$! 4%!08&!@<'!P@(" D)"0H*
M"@L+"PP,# T-#0X.#@\/#Q 0$!$1$1(2$A,3$Q04%!45%186%A<7%Q at 8&!D9
M&1H:&AL;&QP<'!T='1X>'A\?'R @("$A(2(B(B,C(R0D)"4E)28F)B<G)R at H
M*"DI*2HJ*BLK*RPL+"TM+2XN+B\O+S P,#$Q,3(R,C,S,S0T-#4U-38V-C<W
M-S at X.#DY.3HZ.CL[.SP\/#T]/3X^/C\_/T! 0$%!04)"0D-#0T1$1$5%149&
M1D='1TA(2$E)24I*2DM+2TQ,3$U-34Y.3D]/3U!04%%145)24E-34U145%55
M55965E=75UA86%E965I:6EM;6UQ<7%U=75Y>7E]?7V!@8&%A86)B8F-C8V1D
M9&5E969F9F=G9VAH:&EI:6IJ:FMK:VQL;&UM;6YN;F]O;W!P<'%Q<7)R<G-S
M<W1T='5U=79V=G=W=WAX>'EY>7IZ>GM[>WQ\?'U]?7Y^?G]_?X" @(&!@8*"
M at H.#@X2$A(6%A8:&AH>'AXB(B(F)B8J*BHN+BXR,C(V-C8Z.CH^/CY"0D)&1
MD9*2DI.3DY24E)65E9:6EI>7EYB8F)F9F9J:FIN;FYR<G)V=G9Z>GI^?GZ"@
MH*&AH:*BHJ.CHZ2DI*6EI::FIJ>GIZBHJ*FIJ:JJJJNKJZRLK*VMK:ZNKJ^O
MK["PL+&QL;*RLK.SL[2TM+6UM;:VMK>WM[BXN+FYN;JZNKN[N[R\O+V]O;Z^
MOK^_O\# P,'!P<+"PL/#P\3$Q,7%Q<;&QL?'Q\C(R,G)R<K*RLO+R\S,S,W-
MS<[.SL_/S]#0T-'1T=+2TM/3T]34U-75U=;6UM?7U]C8V-G9V=K:VMO;V]S<
MW-W=W=[>WM_?W^#@X.'AX>+BXN/CX^3DY.7EY>;FYN?GY^CHZ.GIZ>KJZNOK
MZ^SL[.WM[>[N[N_O[_#P\/'Q\?+R\O/S\_3T]/7U]?;V]O?W]_CX^/GY^?KZ
M^OO[^_S\_/W]_?[^_O___RP`````! `,```(%P#_`0#P3R!!@P4')CRHL*##
(AQ C/@P(`#L`
`
end

begin 666 omacr.gif
M1TE&.#EA" `*`/<```````$!`0("`@,#`P0$! 4%!08&!@<'!P@(" D)"0H*
M"@L+"PP,# T-#0X.#@\/#Q 0$!$1$1(2$A,3$Q04%!45%186%A<7%Q at 8&!D9
M&1H:&AL;&QP<'!T='1X>'A\?'R @("$A(2(B(B,C(R0D)"4E)28F)B<G)R at H
M*"DI*2HJ*BLK*RPL+"TM+2XN+B\O+S P,#$Q,3(R,C,S,S0T-#4U-38V-C<W
M-S at X.#DY.3HZ.CL[.SP\/#T]/3X^/C\_/T! 0$%!04)"0D-#0T1$1$5%149&
M1D='1TA(2$E)24I*2DM+2TQ,3$U-34Y.3D]/3U!04%%145)24E-34U145%55
M55965E=75UA86%E965I:6EM;6UQ<7%U=75Y>7E]?7V!@8&%A86)B8F-C8V1D
M9&5E969F9F=G9VAH:&EI:6IJ:FMK:VQL;&UM;6YN;F]O;W!P<'%Q<7)R<G-S
M<W1T='5U=79V=G=W=WAX>'EY>7IZ>GM[>WQ\?'U]?7Y^?G]_?X" @(&!@8*"
M at H.#@X2$A(6%A8:&AH>'AXB(B(F)B8J*BHN+BXR,C(V-C8Z.CH^/CY"0D)&1
MD9*2DI.3DY24E)65E9:6EI>7EYB8F)F9F9J:FIN;FYR<G)V=G9Z>GI^?GZ"@
MH*&AH:*BHJ.CHZ2DI*6EI::FIJ>GIZBHJ*FIJ:JJJJNKJZRLK*VMK:ZNKJ^O
MK["PL+&QL;*RLK.SL[2TM+6UM;:VMK>WM[BXN+FYN;JZNKN[N[R\O+V]O;Z^
MOK^_O\# P,'!P<+"PL/#P\3$Q,7%Q<;&QL?'Q\C(R,G)R<K*RLO+R\S,S,W-
MS<[.SL_/S]#0T-'1T=+2TM/3T]34U-75U=;6UM?7U]C8V-G9V=K:VMO;V]S<
MW-W=W=[>WM_?W^#@X.'AX>+BXN/CX^3DY.7EY>;FYN?GY^CHZ.GIZ>KJZNOK
MZ^SL[.WM[>[N[N_O[_#P\/'Q\?+R\O/S\_3T]/7U]?;V]O?W]_CX^/GY^?KZ
M^OO[^_S\_/W]_?[^_O___RP`````" `*```((0#_`1 at X\)_!@P at 3)B2($,!!
2AP(71FPX\:%!B!4%%C08$ `[
`
end

begin 666 schwa.gif
M1TE&.#EA" `(`/<```````$!`0("`@,#`P0$! 4%!08&!@<'!P@(" D)"0H*
M"@L+"PP,# T-#0X.#@\/#Q 0$!$1$1(2$A,3$Q04%!45%186%A<7%Q at 8&!D9
M&1H:&AL;&QP<'!T='1X>'A\?'R @("$A(2(B(B,C(R0D)"4E)28F)B<G)R at H
M*"DI*2HJ*BLK*RPL+"TM+2XN+B\O+S P,#$Q,3(R,C,S,S0T-#4U-38V-C<W
M-S at X.#DY.3HZ.CL[.SP\/#T]/3X^/C\_/T! 0$%!04)"0D-#0T1$1$5%149&
M1D='1TA(2$E)24I*2DM+2TQ,3$U-34Y.3D]/3U!04%%145)24E-34U145%55
M55965E=75UA86%E965I:6EM;6UQ<7%U=75Y>7E]?7V!@8&%A86)B8F-C8V1D
M9&5E969F9F=G9VAH:&EI:6IJ:FMK:VQL;&UM;6YN;F]O;W!P<'%Q<7)R<G-S
M<W1T='5U=79V=G=W=WAX>'EY>7IZ>GM[>WQ\?'U]?7Y^?G]_?X" @(&!@8*"
M at H.#@X2$A(6%A8:&AH>'AXB(B(F)B8J*BHN+BXR,C(V-C8Z.CH^/CY"0D)&1
MD9*2DI.3DY24E)65E9:6EI>7EYB8F)F9F9J:FIN;FYR<G)V=G9Z>GI^?GZ"@
MH*&AH:*BHJ.CHZ2DI*6EI::FIJ>GIZBHJ*FIJ:JJJJNKJZRLK*VMK:ZNKJ^O
MK["PL+&QL;*RLK.SL[2TM+6UM;:VMK>WM[BXN+FYN;JZNKN[N[R\O+V]O;Z^
MOK^_O\# P,'!P<+"PL/#P\3$Q,7%Q<;&QL?'Q\C(R,G)R<K*RLO+R\S,S,W-
MS<[.SL_/S]#0T-'1T=+2TM/3T]34U-75U=;6UM?7U]C8V-G9V=K:VMO;V]S<
MW-W=W=[>WM_?W^#@X.'AX>+BXN/CX^3DY.7EY>;FYN?GY^CHZ.GIZ>KJZNOK
MZ^SL[.WM[>[N[N_O[_#P\/'Q\?+R\O/S\_3T]/7U]?;V]O?W]_CX^/GY^?KZ
M^OO[^_S\_/W]_?[^_O___RP`````" `(```('0#_"1Q($(!!``,1)B2X\-_!
. at P(51IS8T"'$?P$!`#L`
`
end




From steve.lhomme at free.fr  Thu May 13 14:14:33 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Thu, 13 May 2004 14:14:33 +0200
Subject: [Matroska-devel] New Meeting
Message-ID: <40A366A9.5000909@free.fr>

Hi,

I think it would be nice to have a new meeting to discuss the future of 
Matroska and all our sides projects. Would tomorrow (european) evening 
fit everyone ?

In particular I would also like to discuss the disappearance of the 
server we use for the Matroska pack and other stuff. Could we host that 
content on CoreCodec or should we pay for another host (I can if it's 
not too much) ?



From moritz at bunkus.org  Thu May 13 14:25:19 2004
From: moritz at bunkus.org (Moritz Bunkus)
Date: Thu, 13 May 2004 14:25:19 +0200
Subject: [Matroska-devel] New Meeting
In-Reply-To: <40A366A9.5000909@free.fr>
References: <40A366A9.5000909@free.fr>
Message-ID: <20040513122519.GE22839@bunkus.org>

i,

> I think it would be nice to have a new meeting to discuss the future of 
> Matroska and all our sides projects. Would tomorrow (european) evening 
> fit everyone ?

I will probably not be present. My diploma thesis has to be done by
Monday, so I won't have much of a mind for these things, sorry.

> In particular I would also like to discuss the disappearance of the 
> server we use for the Matroska pack and other stuff. Could we host that 
> content on CoreCodec or should we pay for another host (I can if it's 
> not too much) ?

Oh? Didn't know we had problems with the server. What is it? Too much
traffic?

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 alexander.noe at s2001.tu-chemnitz.de  Thu May 13 14:33:12 2004
From: alexander.noe at s2001.tu-chemnitz.de (=?ISO-8859-1?Q?Alexander_No=E9?=)
Date: Thu, 13 May 2004 14:33:12 +0200
Subject: [Matroska-devel] New Meeting
In-Reply-To: <40A366A9.5000909@free.fr>
References: <40A366A9.5000909@free.fr>
Message-ID: <40A36B08.6000301@hrz.tu-chemnitz.de>

Steve Lhomme wrote:

> Hi,
> 
> I think it would be nice to have a new meeting to discuss the future of 
> Matroska and all our sides projects. Would tomorrow (european) evening 
> fit everyone ?

The next 6 fridays/saturdays won't fit for me.


Alex



From steve.lhomme at free.fr  Thu May 13 14:37:52 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Thu, 13 May 2004 14:37:52 +0200
Subject: [Matroska-devel] New Meeting
In-Reply-To: <20040513122519.GE22839@bunkus.org>
References: <40A366A9.5000909@free.fr> <20040513122519.GE22839@bunkus.org>
Message-ID: <40A36C20.5090408@free.fr>

Moritz Bunkus a ?crit :

>>I think it would be nice to have a new meeting to discuss the future of 
>>Matroska and all our sides projects. Would tomorrow (european) evening 
>>fit everyone ?
> 
> 
> I will probably not be present. My diploma thesis has to be done by
> Monday, so I won't have much of a mind for these things, sorry.

Great ! That means you'll have more time afterward ;)
Seriously I hope it works well for you.

>>In particular I would also like to discuss the disappearance of the 
>>server we use for the Matroska pack and other stuff. Could we host that 
>>content on CoreCodec or should we pay for another host (I can if it's 
>>not too much) ?
> 
> 
> Oh? Didn't know we had problems with the server. What is it? Too much
> traffic?

No idea. Atomic could say more about it. But it's supposed to be off by 
the middle of June IIRC.



From steve.lhomme at free.fr  Thu May 13 15:17:02 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Thu, 13 May 2004 15:17:02 +0200
Subject: [Matroska-devel] Re: Re: Tag names
In-Reply-To: <c7vghk$vu9$1@sea.gmane.org>
References: <40532BBD.8060909@home.nl>
	<c2vl69$l03$1@sea.gmane.org>	<4054B190.7050008@home.nl>
	<c7vghk$vu9$1@sea.gmane.org>
Message-ID: <40A3754E.2040204@free.fr>

Paul Bryson a ?crit :

> Where do you store the Episode Number, Production Code, and Synopsis?  Also,
> when you list an actor, how do you say the character that they played?  A quick
> assigning produced this:
> 
> <Name>SET_TITLE</Name>
> <String>Season 1</String>
> 
> <Name>SERIES</Name>
> <String>24</String>
> 
> <Name>TITLE</Name>
> <String>Episode 1</String>
> 
> <Name>SUBTITLE</Name>
> <String>12:00 A.M.-1:00 A.M.</String>
> 
> <Name>DATE_RELEASE</Name>
> <String>November 6, 2001</String>
> 
> <Name>WRITER</Name>
> <String>Robert Cochran</String>
> 
> <Name>DIRECTOR</Name>
> <String>Stephen Hopkins</String>
> 
> <Name>INVOLVED_PERSON</Name>
> <String>Mia Kirshner</String>
> 
> <Name>SYNOPSIS</Name>
> <String>Jack Bauer, an agent for the CIA...</String>
> 
> I don't think the TITLE and SUBTITLE are being used correctly for this right
> now.  I really think the Episode number could be stored using current tags, but
> I'm not sure how at the moment.  (possibly SET_PART?)  I am pretty sure that a

It's like the track number of an album so should be treated the same way.

> PRODUCTION_CODE needs to be added to the Identifiers section.  For the Character
> being played, it should be easy to create a nested tag to the INVOLVED_PERSON
> tag, but it needs a name.  The two that I could think of are ROLE and CHARACTER.

Do we really want a whole database inside a Matroska file ? What about 
pictures of the actors or some of the scenes in the movie ? I'm sure you 
can find all this in an interactive website but it's probably useless to 
be embedded in the file.

>>Should we add CUESHEET and LOGFILE? Although I don't like the idea of
>>storing a complete file into a tag field, it has it's advantages.
>>Personally I prefer a URI to the file in those fields but it's not being
>>used this way. (we could allow both? :-S)
> 
> 
> It won't go in the Matroska tags as Matroska has a specific way to store files
> in it and define what they are.  In fact you can make tags for the files.

Plus I don't think you can beat a CUESHEET to define what is on the 
original CD.

> Except that 'performer' makes much more sense in terms of actors than 'artist'
> does.  An actor can be referred to as an artist, but it is uncommon.  But it
> needs to be given further consideration.

Maybe in the USA, but here it makes sense ! In the other hand I find the 
name "performer" ugly.

>>I'll just list his stuff one by one:
>>- COMPOSITION
>>Should be added or maybe even a sublevel should be created to fit in all
>>the classical fields stuff.
> 
> 
> I honestly don't know that much about organizational and linguistic structure
> within classical music.  But couldn't the Composition name be stored in a tag
> that already exists in the Titles section?  What is particular about it that
> makes it not fit in any of those?  Would it be wrong to store the composition's
> name in TITLE and the composition's part name in SUBTITLE?

Strange issue, because in iTunes you can already set the composer. So I 
assume it already exists for MP3.

>>- OPUS and OPUSNUMBER
>>I'm not sure how to deal with OPUS and OPUSNUMBER.
> 
> 
> Pronunciation: ps, chiefly British ?p-
> Function: noun
> Inflected Form(s): plural opera \pr, ?p-\; also opuses
> Etymology: Latin oper- opus -- more at OPERATE
> : WORK: as a : a musical composition or set of compositions usually numbered in
> the order of its issue -- abbr. op
> 
> I have no idea what those are used for or how they are used.  Perhaps this would
> be something else that would go under the Identifiers section?

I think it's like having 3 albums making a trilogy. Maybe it would apply 
to movies too.



From moritz at bunkus.org  Thu May 13 15:25:37 2004
From: moritz at bunkus.org (Moritz Bunkus)
Date: Thu, 13 May 2004 15:25:37 +0200
Subject: [Matroska-devel] New Meeting
In-Reply-To: <40A36C20.5090408@free.fr>
References: <40A366A9.5000909@free.fr> <20040513122519.GE22839@bunkus.org>
	<40A36C20.5090408@free.fr>
Message-ID: <20040513132537.GF22839@bunkus.org>

Hi,

> Great ! That means you'll have more time afterward ;)

We'll see ;) There's still the presentation left that I'll have to do
about it, but overall the situation should improve. Not next week
though, too much to do.

> No idea. Atomic could say more about it. But it's supposed to be off by 
> the middle of June IIRC.

I've found it in the logs:

.17:20:12. @ChrisHJW:: atomic_ will only have the server until 27th May
.17:20:22. @ChrisHJW:: we have to get all our data from there

I can't provide hosting for the packs myself, the traffic is too much.

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  Thu May 13 18:08:20 2004
From: paul at msn.com (Paul Bryson)
Date: Thu, 13 May 2004 11:08:20 -0500
Subject: [Matroska-devel] Re: New Meeting
References: <40A366A9.5000909@free.fr>
	<20040513122519.GE22839@bunkus.org><40A36C20.5090408@free.fr>
	<20040513132537.GF22839@bunkus.org>
Message-ID: <c806h9$ra9$1@sea.gmane.org>

"Moritz Bunkus" wrote...
> I can't provide hosting for the packs myself, the traffic is too much.

Bah, 80GB/month is nothing.   ;)


Pamel





From steve.lhomme at free.fr  Thu May 13 19:11:10 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Thu, 13 May 2004 19:11:10 +0200
Subject: [Matroska-devel] Re: New Meeting
In-Reply-To: <c806h9$ra9$1@sea.gmane.org>
References: <40A366A9.5000909@free.fr>	<20040513122519.GE22839@bunkus.org><40A36C20.5090408@free.fr>	<20040513132537.GF22839@bunkus.org>
	<c806h9$ra9$1@sea.gmane.org>
Message-ID: <40A3AC2E.5060209@free.fr>

Paul Bryson wrote:
> "Moritz Bunkus" wrote...
> 
>>I can't provide hosting for the packs myself, the traffic is too much.
> 
> 
> Bah, 80GB/month is nothing.   ;)

I'm currently looking for alternative solutions. I have already found 
some with unlimited and fast traffic. We would have complete (root) 
control on a Debian machine. I have found a few options to do that. Now 
let's see if we can merge costs with CoreCodec...


From tronic at trn.iki.fi  Fri May 14 00:37:39 2004
From: tronic at trn.iki.fi (=?ISO-8859-1?Q?Lasse_K=E4rkk=E4inen_/_Tronic?=)
Date: Fri, 14 May 2004 01:37:39 +0300
Subject: [Matroska-devel] New Meeting
In-Reply-To: <40A366A9.5000909@free.fr>
References: <40A366A9.5000909@free.fr>
Message-ID: <40A3F8B3.4040401@trn.iki.fi>

> I think it would be nice to have a new meeting to discuss the future of 
> Matroska and all our sides projects. Would tomorrow (european) evening 
> fit everyone ?

Very good time for me. I have the last exam today (9-13 EET) and only 
one (not tightly scheduled) project work after that => I'm free 14+ EET.

In particular, I'd like to discuss the future of EBML. A schema format 
would need to be defined, as well as new data types and structures 
(references?). <we need XML killer>

- Tronic -

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20040514/7306842f/attachment.pgp>

From spyder at matroska.org  Fri May 14 03:16:56 2004
From: spyder at matroska.org (John Cannon)
Date: Thu, 13 May 2004 20:16:56 -0500
Subject: [Matroska-devel] New Meeting
In-Reply-To: <40A366A9.5000909@free.fr>
References: <40A366A9.5000909@free.fr>
Message-ID: <40A41E08.6010700@matroska.org>

Steve Lhomme wrote:

> Hi,
>
> I think it would be nice to have a new meeting to discuss the future 
> of Matroska and all our sides projects. Would tomorrow (european) 
> evening fit everyone ?
>
> In particular I would also like to discuss the disappearance of the 
> server we use for the Matroska pack and other stuff. Could we host 
> that content on CoreCodec or should we pay for another host (I can if 
> it's not too much) ?
>
> _______________________________________________
> Matroska-devel mailing list
> Matroska-devel at lists.matroska.org
> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
>
I will be home at about 1pm my time, that's about 20:00 your time IIRC.  
But next week I should have no problem with any time :)  My last final 
is tomorrow morning.

John


From paul at msn.com  Fri May 14 07:12:38 2004
From: paul at msn.com (Paul Bryson)
Date: Fri, 14 May 2004 00:12:38 -0500
Subject: [Matroska-devel] Re: New Meeting
References: <40A366A9.5000909@free.fr>
Message-ID: <c81kg0$ifp$1@sea.gmane.org>

"Steve Lhomme" wrote...
> Hi,
>
> I think it would be nice to have a new meeting to discuss the future of
> Matroska and all our sides projects. Would tomorrow (european) evening
> fit everyone ?

I will likely be working still at that time.


Pamel





From paul at msn.com  Fri May 14 08:05:59 2004
From: paul at msn.com (Paul Bryson)
Date: Fri, 14 May 2004 01:05:59 -0500
Subject: [Matroska-devel] Re: Re: Re: Tag names
References: <40532BBD.8060909@home.nl><c2vl69$l03$1@sea.gmane.org>	<4054B190.7050008@home.nl><c7vghk$vu9$1@sea.gmane.org>
	<40A3754E.2040204@free.fr>
Message-ID: <c81nk0$n6f$1@sea.gmane.org>

"Steve Lhomme" wrote...
Paul Bryson a ?crit :
> > I don't think the TITLE and SUBTITLE are being used correctly for this right
> > now.  I really think the Episode number could be stored using current tags,
but
> > I'm not sure how at the moment.  (possibly SET_PART?)  I am pretty sure that
a
>
> It's like the track number of an album so should be treated the same way.

So, store the episode number in SET_PART and the total number of episodes in
TOTAL_SET_PART.

> > PRODUCTION_CODE needs to be added to the Identifiers section.  For the
Character
> > being played, it should be easy to create a nested tag to the
INVOLVED_PERSON
> > tag, but it needs a name.  The two that I could think of are ROLE and
CHARACTER.
>
> Do we really want a whole database inside a Matroska file ? What about
> pictures of the actors or some of the scenes in the movie ? I'm sure you
> can find all this in an interactive website but it's probably useless to
> be embedded in the file.

Its useful if you want to find the info without going to a website.  Remember,
this is information that somebody actually want to store in a Matroska file
right now.

> >>Should we add CUESHEET and LOGFILE? Although I don't like the idea of
> >>storing a complete file into a tag field, it has it's advantages.
> >>Personally I prefer a URI to the file in those fields but it's not being
> >>used this way. (we could allow both? :-S)
> >
> > It won't go in the Matroska tags as Matroska has a specific way to store
files
> > in it and define what they are.  In fact you can make tags for the files.
>
> Plus I don't think you can beat a CUESHEET to define what is on the
> original CD.

I'm not sure I understand the point you are trying to make.

> > Except that 'performer' makes much more sense in terms of actors than
'artist'
> > does.  An actor can be referred to as an artist, but it is uncommon.  But it
> > needs to be given further consideration.
>
> Maybe in the USA, but here it makes sense ! In the other hand I find the
> name "performer" ugly.

Your just jealous that my weapons of mass destruction are bigger than your
weapons of mass destruction.

> >>I'll just list his stuff one by one:
> >>- COMPOSITION
> >>Should be added or maybe even a sublevel should be created to fit in all
> >>the classical fields stuff.
> >
> > I honestly don't know that much about organizational and linguistic
structure
> > within classical music.  But couldn't the Composition name be stored in a
tag
> > that already exists in the Titles section?  What is particular about it that
> > makes it not fit in any of those?  Would it be wrong to store the
composition's
> > name in TITLE and the composition's part name in SUBTITLE?
>
> Strange issue, because in iTunes you can already set the composer. So I
> assume it already exists for MP3.

"Composer" is not the same as "Composition".  One is the writer, and one is the
work.

> >>- OPUS and OPUSNUMBER
> >>I'm not sure how to deal with OPUS and OPUSNUMBER.
> >
> > I have no idea what those are used for or how they are used.  Perhaps this
would
> > be something else that would go under the Identifiers section?
>
> I think it's like having 3 albums making a trilogy. Maybe it would apply
> to movies too.

I posted in the HA.org thread that mentioned this to get a little more
information.


Pamel





From steve.lhomme at free.fr  Fri May 14 09:51:22 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Fri, 14 May 2004 09:51:22 +0200
Subject: [Matroska-devel] Re: New Meeting
In-Reply-To: <40A3AC2E.5060209@free.fr>
References: <40A366A9.5000909@free.fr>	<20040513122519.GE22839@bunkus.org><40A36C20.5090408@free.fr>	<20040513132537.GF22839@bunkus.org>	<c806h9$ra9$1@sea.gmane.org>
	<40A3AC2E.5060209@free.fr>
Message-ID: <40A47A7A.8000801@free.fr>

Steve Lhomme wrote:

> Paul Bryson wrote:
> 
>> "Moritz Bunkus" wrote...
>>
>>> I can't provide hosting for the packs myself, the traffic is too much.
>>
>>
>>
>> Bah, 80GB/month is nothing.   ;)
> 
> 
> I'm currently looking for alternative solutions. I have already found 
> some with unlimited and fast traffic. We would have complete (root) 
> control on a Debian machine. I have found a few options to do that. Now 
> let's see if we can merge costs with CoreCodec...

OK, after discussing with the CoreCodec people (Cytoplas and Betaboy) it 
seems that they can't really provide the bandwidth for us and they don't 
want to move their servers to another place. Also the bigger issue in 
the Intellectual Property and patent covered binaries. As CC is hosted 
in the USA they are much more subject to Cease and Disist letters and 
maybe harder actions. So it's just not possible to host certain binaries 
there, nor anywhere else in the USA (otherwise that would just be the same).

So where does it leave us ? We need our packs the way they are, because 
otherwise it's a mess for lambda users to have something working. And we 
are working for the users...

So we need a place that could provide the bandwidth and traffic for our 
packs. The options I can see :

- free.fr : it was the place where it used to be, and I don't remember 
the reason why we left. Can anybody enligthen me ?

- SourceForge : after all they are hosting so many stuff that might 
infringe patents, we don't really care for the time being

- Leased dedicated server : we could administer our own site the way 
Mosu uses his one. I've checked some places in France and some are 
really cool. But we may have software patents in Europe very soon. So I 
think it should be good to look further like in Russia, India, China or 
whatever where patent claims are less likely to happen.

So what do everyone thinks about it ?

I don't think there is such a pressure to go hosting our stuff overseas. 
After all noone threaten to sue us and we are not that big right now (it 
will be time to move later when needed).



From agebosma at home.nl  Fri May 14 19:28:31 2004
From: agebosma at home.nl (Age Bosma)
Date: Fri, 14 May 2004 19:28:31 +0200
Subject: [Matroska-devel] Re: Re: Tag names
In-Reply-To: <c7vghk$vu9$1@sea.gmane.org>
References: <40532BBD.8060909@home.nl>
	<c2vl69$l03$1@sea.gmane.org>	<4054B190.7050008@home.nl>
	<c7vghk$vu9$1@sea.gmane.org>
Message-ID: <40A501BF.2020500@home.nl>

Paul Bryson wrote:
> 
> I don't think the TITLE and SUBTITLE are being used correctly for this right
> now.  I really think the Episode number could be stored using current tags, but
> I'm not sure how at the moment.  (possibly SET_PART?)  

I agree with Steve to treat this information as track numbers because it 
basicly is, so in the current Matroska fields this info should be stored 
in the SET_PART fields.
On the other hand, taking it one step further and suppose we want to add 
scene info, SET_PART should be used for this and MEDIA_PART would be 
more suitable for the episode info. What do you think?

> I am pretty sure that a
> PRODUCTION_CODE needs to be added to the Identifiers section.

Kind of agree, but what about the current LABEL_CODE?

> For the Character
> being played, it should be easy to create a nested tag to the INVOLVED_PERSON
> tag, but it needs a name.

Like you stated before "INVOLVED_PERSON could be someone like a gaffer 
or a makeup artist." so it would be right to character info.

> The two that I could think of are ROLE and CHARACTER.
> The word 'role' is very specific in its meaning, leaving little possibility to
> get it wrong.  However, the word 'character' may fit better, even though it can
> have many possible definitions that could confuse.  I am guessing CHARACTER.
> What do you think?

I agree on CHARACTER, this would be more suitable to store the name an 
actor is playing. ROLE would be better to store info about the actual 
role an actor is playing e.g. "The bad cop".

>>Should we add CUESHEET and LOGFILE? Although I don't like the idea of
>>storing a complete file into a tag field, it has it's advantages.
>>Personally I prefer a URI to the file in those fields but it's not being
>>used this way. (we could allow both? :-S) 
> 
> It won't go in the Matroska tags as Matroska has a specific way to store files
> in it and define what they are.  In fact you can make tags for the files.

I don't follow on this one...

>>Something in the line of ALBUM_ARTIST should be added but if we add it
>>like this I think we should change LEAD_PERFORMER to ARTIST like I
>>suggested before as well. For a consistency point of view it would
>>cause confusing when we add ALBUM_ARTIST if there isn't a normal ARTIST
>>field in the first place. We could also change it to
>>ALBUM_LEAD_PERFORMER but imo LEAD_PERFORMER doesn't make much sense in
>>the first place (check my reference to see what I mean). 
> 
> Except that 'performer' makes much more sense in terms of actors than 'artist'
> does.  An actor can be referred to as an artist, but it is uncommon.  But it
> needs to be given further consideration.

If a seperate level is going to be created for actors this field would 
be redundant to store actor information. Also because in movies in most 
cases there are multiple lead performers. Because of this ARTIST could 
be used only in case of music.

>>I'll just list his stuff one by one:
>>- COMPOSITION
>>Should be added or maybe even a sublevel should be created to fit in all
>>the classical fields stuff. 
> 
> I honestly don't know that much about organizational and linguistic structure
> within classical music.  But couldn't the Composition name be stored in a tag
> that already exists in the Titles section?  What is particular about it that
> makes it not fit in any of those?  Would it be wrong to store the composition's
> name in TITLE and the composition's part name in SUBTITLE?
> 
> 
>>- COMPOSITION PART
>>I do however don't like the idea to use it the way he does. E.g.
>>COMPOSITION PART1 and COMPOSITION PART2 as field names. Is there already
>>a way to use the same field multiple more than once?
> 
> For storing the number of the part, I would just add COMPOSITION_PART and
> TOTAL_COMPOSITION_PARTS.  For each item, name the Composition, Composition part,
> and the number.
> 
> 
>>- COMPOSITION DATE
>>DATE_COMPOSITION could be added, as far as I can see there isn't an
>>alternative yet.
> 
> I added DATE_COMPOSITION.  However, I would like to use this field to also
> describe when a script for a movie was made.  Is there a more generic name that
> could be used?
>  

I disagree, script dates are something completely different.

To tell you the truth, I should know all the movie info stuff because of 
my education :-$
I'll make an appointment with my teacher to go through all the stuff 
about movies again, all important info that should be included, how it 
should be included, etc. and try to create a complete list. I think 
might give us a more complete overview.

Also, a different teacher of mine, who also works in a music 
conservatory. might be able to help out on our classical music issues. 
I'll get in contact with him as well.

>>- OPUS and OPUSNUMBER
>>I'm not sure how to deal with OPUS and OPUSNUMBER.
> 
>  ...
> 
> I have no idea what those are used for or how they are used.  Perhaps this would
> be something else that would go under the Identifiers section?

Looking at guruboolez's reply I agree on that one.

I updated my list to your changes but I found one error:

/DATE_ENCODING/
/The time that the encoding of this item was completed began./

What did you ment to say here? "completed", "began" or "completed/began"?
Because of the changes you made to the DATE_RECORDING description I 
would say it has to be just "began".

I also updated the OGG tag fields according to the list superjaded 
pointed to. A few OGG fields are a bit problematic now:

* LABEL - the record label or imprint on the disc
As far as I can see there's no suitable equivalent in the Matroska tag 
set but I'm unsure it should be included in the first place because 
there are other fields available.

* OPUS - the number of the work; eg, Opus 10, BVW 81, K6
Like you mentioned this can be added to the Identifiers section.

* ARRANGER - the person who arranged the piece, eg, Ravel
Wouldn't this be the same as COMPOSER? the OGG set included both.

* PERFORMER - individual performers singled out for mention; eg, Yoyo Ma 
(violinist)
Although the OGG set includes ARTIST, PERFORMER seems to be treated 
differently. Maybe we should have both (LEAD_)PERFORMER and ARTIST as well?

* PART - a division within a work; eg, a movement of a symphony. Some 
tracks contain several parts.
Again, SET_PART_TITLE and MEDIA_PART_TITLE comes to mind.

* PARTNUMBER - The part number goes in here.
SET_PART could be an equivalent but the OGG set also contains a 
TRACKNUMBER field...

* DESCRIPTION
This is one from the first OGG field list I included. This one seems to 
be replaced by COMMENT in the new list. As far as I can tell there isn't 
a need to add a new field for this one.
I noticed that the Matroska tag set contains COMMENTS instead of COMMENT 
while the description is talking about a single comment. Shouldn't we 
change it to COMMENT as well? This is also what all other tag sets use.

Cheers,

Age Bosma


From agebosma at home.nl  Sat May 15 14:55:29 2004
From: agebosma at home.nl (Age Bosma)
Date: Sat, 15 May 2004 14:55:29 +0200
Subject: [Matroska-devel] Re: Re: Tag names
In-Reply-To: <40A501BF.2020500@home.nl>
References: <40532BBD.8060909@home.nl>	<c2vl69$l03$1@sea.gmane.org>	<4054B190.7050008@home.nl>	<c7vghk$vu9$1@sea.gmane.org>
	<40A501BF.2020500@home.nl>
Message-ID: <40A61341.8060805@home.nl>

Age Bosma wrote:

> 
> * PART - a division within a work; eg, a movement of a symphony. Some 
> tracks contain several parts.
> Again, SET_PART_TITLE and MEDIA_PART_TITLE comes to mind.
> 

Stupid mistake, forget the suggestion. If SET_PART is treated like 
tracknumber it will already have support for a name using the TITLE field.


From steve.lhomme at free.fr  Sun May 30 11:22:43 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Sun, 30 May 2004 11:22:43 +0200
Subject: [Matroska-devel] Matroska v1
Message-ID: <40B9A7E3.6080701@free.fr>

Hi,

The fix release of Matroska have been pending for a while but is not 
achieved yet. IMO, before we move on to bigger things and other things 
we should get Matroska 1 done.

Here is a list of what I can see before we go v1, correct me if 
something is wrong or missing :

- finish resolving issues that may exist on some tags

- native MPEG4 support (with or without Block 2, it can be discussed), 
IMO we can't go v1 if we don't have native MPEG4 which is probably 80% 
of existing Matroska files.

- native TTA support (lossless audio codec), they are hosted on 
CoreCodec and the format is well described (and very efficient)

- native WavPack support (lossless audio codec), another CoreCodec 
hosted project that is also efficient and also have an hybrid mode 
(lossy and lossless possible), the format may be less well defined but 
are in contact with the main developper David Bryant

The menu system is too complicated and should go for the next release. 
No need to wait any longer for that. And the other issues might take 
considerably less time (everything could be done in a few weeks from now).

What do you all think about that ?


From moritz at bunkus.org  Sun May 30 12:15:45 2004
From: moritz at bunkus.org (Moritz Bunkus)
Date: Sun, 30 May 2004 12:15:45 +0200
Subject: [Matroska-devel] Re: [Matroska-general] Matroska v1
In-Reply-To: <40B9A7E3.6080701@free.fr>
References: <40B9A7E3.6080701@free.fr>
Message-ID: <20040530101544.GM7737@bunkus.org>

Hi,

> - finish resolving issues that may exist on some tags

Pamel should probably comment on that as he has done so much work for
it.

> - native MPEG4 support (with or without Block 2, it can be discussed), 
> IMO we can't go v1 if we don't have native MPEG4 which is probably 80% 
> of existing Matroska files.

Yes, but I'm not really any closer to having a working solution than I
have been four months ago. I'll see if I can work on it during the next
two weeks.

About the Block 2: I don't think we should rush this. Leave the current
block scheme in place in 1.0 and maybe create a new block for after 1.0.

> - native TTA support

and

> - native WavPack support

I don't think that these two are required for 1.0. They're 'would be
nice to have' features, but nothing more. We already have support for
one lossless codec (FLAC), so these two should not stand in the way of
1.0 being released.

> The menu system is too complicated and should go for the next
> release. 

I agree. We won't get that working anytime soon.

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  Sun May 30 12:28:38 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Sun, 30 May 2004 12:28:38 +0200
Subject: [Matroska-devel] Re: Matroska v1
In-Reply-To: <20040530101544.GM7737@bunkus.org>
References: <40B9A7E3.6080701@free.fr> <20040530101544.GM7737@bunkus.org>
Message-ID: <40B9B756.3090501@free.fr>

Moritz Bunkus a ?crit :

>>- native MPEG4 support (with or without Block 2, it can be discussed), 
>>IMO we can't go v1 if we don't have native MPEG4 which is probably 80% 
>>of existing Matroska files.
> 
> 
> Yes, but I'm not really any closer to having a working solution than I
> have been four months ago. I'll see if I can work on it during the next
> two weeks.
> 
> About the Block 2: I don't think we should rush this. Leave the current
> block scheme in place in 1.0 and maybe create a new block for after 1.0.

Good ;)

I'm not against Block2, but for v1 we probably want something stable. 
And the rest of the format hasn't changed for a while. But native 
references are not well used currently in any tool, AFAIK. So I doubt if 
we go with the current system, it will work...

>>- native TTA support
>>- native WavPack support
> 
> 
> I don't think that these two are required for 1.0. They're 'would be
> nice to have' features, but nothing more. We already have support for
> one lossless codec (FLAC), so these two should not stand in the way of
> 1.0 being released.

Yes, but the v1 freezing is not about the code, but the specs. We just 
need to define what we put in CodecPrivate and what goes in the frames, 
nothing more. I'll investigate that, and from that point implementation 
will be easy for everyone.

IMO the time vs benefit ratio is good :) And I really want to support 
both codec in the future. They are good, open source and most of all, 
better than FLAC in many areas.



From chris at matroska.org  Sun May 30 13:07:45 2004
From: chris at matroska.org (Christian HJ Wiesner)
Date: Sun, 30 May 2004 13:07:45 +0200
Subject: [Matroska-devel] Re: [Matroska-general] Matroska v1
In-Reply-To: <20040530101544.GM7737@bunkus.org>
References: <40B9A7E3.6080701@free.fr> <20040530101544.GM7737@bunkus.org>
Message-ID: <40B9C081.6020807@matroska.org>



Moritz Bunkus wrote:
> Hi,
>>- finish resolving issues that may exist on some tags
> Pamel should probably comment on that as he has done so much work for
> it.

Yes, where is Paul :) ?

>>- native MPEG4 support (with or without Block 2, it can be discussed), 
>>IMO we can't go v1 if we don't have native MPEG4 which is probably 80% 
>>of existing Matroska files 
> 
> Yes, but I'm not really any closer to having a working solution than I
> have been four months ago. I'll see if I can work on it during the next
> two weeks.

Sidenote : a working native MPEG4 implementation would be a very good 
thing from a marketing aspect !

> About the Block 2: I don't think we should rush this. Leave the current
> block scheme in place in 1.0 and maybe create a new block for after 1.0.

I fully agree. Overhead should be better compared to most AVIs ( all 
DivX5 AVIs, most XviD AVIs ) even with block 1, and a new block type 
before we go matroska 1.0 is no good thing from a psychological point of 
view IMO.

>>- native TTA support
> 
> and
> 
>>- native WavPack support
> 
> I don't think that these two are required for 1.0. They're 'would be
> nice to have' features, but nothing more. We already have support for
> one lossless codec (FLAC), so these two should not stand in the way of
> 1.0 being released

The number of supported formats has nothing to do with going 1.0 IMO. 
Making matroska 1.0 is a matter of the specs, but not necessarily of the 
codec ID page. We can add support for any of those whenever we like to, 
again IMO.
Besides, any new format we add gives us publicity and we could well use 
some of that right now i guess ....

>>The menu system is too complicated and should go for the next
>>release. 
> 
> I agree. We won't get that working anytime soon.
> Mosu

I had loved to get menues working in 1.0, but it seems we have to live 
with a compromise here, as we currently dont get the support we need 
from the outside world. Only Mosu and robux4 coding, and me doing some 
minor admin help ( with plenty of RL obstacles ) .... we should push 
matroska 1.0 as is now, maybe only adding native MPEG4 .

Christian



From steve.lhomme at free.fr  Sun May 30 13:36:28 2004
From: steve.lhomme at free.fr (Steve Lhomme)
Date: Sun, 30 May 2004 13:36:28 +0200
Subject: [Matroska-devel] Re: Matroska v1
In-Reply-To: <40B9C081.6020807@matroska.org>
References: <40B9A7E3.6080701@free.fr> <20040530101544.GM7737@bunkus.org>
	<40B9C081.6020807@matroska.org>
Message-ID: <40B9C73C.5090002@free.fr>

Christian HJ Wiesner a ?crit :

> 
> 
> Moritz Bunkus wrote:
> 
>> Hi,
>>
>>> - finish resolving issues that may exist on some tags
>>
>> Pamel should probably comment on that as he has done so much work for
>> it.
> 
> 
> Yes, where is Paul :) ?

Maybe the timing is bad. He said yesterday on IRC that he won't have 
internet for 2 weeks :(

Seems we are out of luck these days...

>>> - native MPEG4 support (with or without Block 2, it can be 
>>> discussed), IMO we can't go v1 if we don't have native MPEG4 which is 
>>> probably 80% of existing Matroska files 
>>
>>
>> Yes, but I'm not really any closer to having a working solution than I
>> have been four months ago. I'll see if I can work on it during the next
>> two weeks.
> 
> 
> Sidenote : a working native MPEG4 implementation would be a very good 
> thing from a marketing aspect !

As I said to Chris on IRC, I was thinking yesterday of getting rid of 
all the AVIs I have a convert them to MKV. But most of them are DivX 
encoded, and that would be silly to do it when native MPEG4 support is 
pending... So I'll wait for this support to do it... Maybe other people 
are thinking the same too !

> The number of supported formats has nothing to do with going 1.0 IMO. 
> Making matroska 1.0 is a matter of the specs, but not necessarily of the 
> codec ID page. We can add support for any of those whenever we like to, 
> again IMO.
> Besides, any new format we add gives us publicity and we could well use 
> some of that right now i guess ....

So you think we should support these codecs before v1 ? (IMO it will be 
done faster than doing v1) BTW this is the same issue as native MPEG4. 
Except that for native MPEG4 we need to test references that were never 
tested before...



From spyder at matroska.org  Sun May 30 22:27:30 2004
From: spyder at matroska.org (John Cannon)
Date: Sun, 30 May 2004 15:27:30 -0500
Subject: [Matroska-devel] Re: Matroska v1
In-Reply-To: <40B9C73C.5090002@free.fr>
References: <40B9A7E3.6080701@free.fr>
	<20040530101544.GM7737@bunkus.org>	<40B9C081.6020807@matroska.org>
	<40B9C73C.5090002@free.fr>
Message-ID: <40BA43B2.8010906@matroska.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Yes, Paul seems to be away for a while.  I think we should try too
finish this up as soon as possible but we really need Paul to help
finalize the tags.  I agree with Mosu about the lossless codecs.  I'm
not sure if this is necessary for the v1 release.  However, I guess we
have time to get that figured out while Paul is away...

@Chris: Welcome back :)

John
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAukOypVzSUDd/cNwRAuHMAJ9KrlOLxuglVJA+tIYbgZMXJjX1nACgjnFg
grvZQ5tEzsvE4KdbsmquTRA=
=Tj+e
-----END PGP SIGNATURE-----