From steve.lhomme at free.fr Tue May 1 15:25:05 2007 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 01 May 2007 15:25:05 +0200 Subject: [Matroska-general] Matroska 4th public birthday Message-ID: <46373FB1.30208@free.fr> Hi everyone, Today is the 4th birthday of the first matroska public release ! We've come a long way and achieved a lot during that time. We didn't reach the initial goal of being used as a file format to edit files. But we are used by many people to make their encodings in the best possible quality and with all the features they want. Nobody can now dismiss matroska and its users, even though we still don't have any native hardware support. Although matroska may seem a bit dormant, we are all still working on it. Either adding more codec support (Mosu, Haali), trying to enhance it (discussions on DRM and enhanced EBML) or make it more audio friendly (foobar2k). There's also the 1.0 version of Perian that will be released soon that will add matroska support in QuickTime (OS X only for now) and therefore iTunes. And the google Summer Of Code in VLC and FFMPEG to add a muxer to each program. On the CoreCodec side (who I work for) CorePlayer has matroska support on Windows CE, Palm OS and Symbian (to be released soon). The new version will have a media library that will make use of matroska tags. That can be browsed like iTunes on these devices. So now everyone should tag their files extensively for better sorting and browsing. A big thanks to all the continued support from developpers and the growing user base :) Steve -- robUx4 on blog From chris at matroska.org Tue May 1 17:41:36 2007 From: chris at matroska.org (Christian HJ Wiesner) Date: Tue, 01 May 2007 17:41:36 +0200 Subject: [Matroska-general] Matroska 4th public birthday In-Reply-To: <46373FB1.30208@free.fr> References: <46373FB1.30208@free.fr> Message-ID: <46375FB0.8020104@matroska.org> Hi All, i actually had the same idea as Steve, to send an email about matroska's 4th b-day to the list. As he has done this already now, i am planning to update our news entries in English and German tonight. Haali is just telling me the Russian pages are completely outdated, he suggested to better kill them then leaving them as they are now. Maybe somebody on this list from Russia can motivate himself to at least add a hint to the Russian pages, suggesting to better brose the English pages for more actual information ? Its exciting that the project has come such a long way, and IMO it also was to the benefit of matroska, the container, that there hasn't been so much updating lately, for stability reasons. If a project is under heavy development, compatibility is sometimes a problem. Still, i do hope there is some revitalization of the menues, and its good to hear that finally matroska tags are going to be used. For the future i wish everybody who was ever involved in the project does feel as proud as i am, to have helped a little bit to make matroska develop to what it is today. Christian matroska project admin Steve Lhomme schrieb: > Hi everyone, > > Today is the 4th birthday of the first matroska public release ! > > We've come a long way and achieved a lot during that time. We didn't > reach the initial goal of being used as a file format to edit files. > But we are used by many people to make their encodings in the best > possible quality and with all the features they want. Nobody can now > dismiss matroska and its users, even though we still don't have any > native hardware support. > > Although matroska may seem a bit dormant, we are all still working on > it. Either adding more codec support (Mosu, Haali), trying to enhance > it (discussions on DRM and enhanced EBML) or make it more audio > friendly (foobar2k). There's also the 1.0 version of Perian that will > be released soon that will add matroska support in QuickTime (OS X > only for now) and therefore iTunes. And the google Summer Of Code in > VLC and FFMPEG to add a muxer to each program. > > On the CoreCodec side (who I work for) CorePlayer has matroska support > on Windows CE, Palm OS and Symbian (to be released soon). The new > version will have a media library that will make use of matroska tags. > That can be browsed like iTunes on these devices. So now everyone > should tag their files extensively for better sorting and browsing. > > A big thanks to all the continued support from developpers and the > growing user base :) > > Steve > From steve.lhomme at free.fr Tue May 1 18:01:54 2007 From: steve.lhomme at free.fr (Steve Lhomme) Date: Tue, 01 May 2007 18:01:54 +0200 Subject: [Matroska-general] Matroska 4th public birthday In-Reply-To: <46375FB0.8020104@matroska.org> References: <46373FB1.30208@free.fr> <46375FB0.8020104@matroska.org> Message-ID: <46376472.9070404@free.fr> Christian HJ Wiesner wrote: > Hi All, > > i actually had the same idea as Steve, to send an email about matroska's > 4th b-day to the list. As he has done this already now, i am planning to > update our news entries in English and German tonight. > > Haali is just telling me the Russian pages are completely outdated, he > suggested to better kill them then leaving them as they are now. Maybe > somebody on this list from Russia can motivate himself to at least add a > hint to the Russian pages, suggesting to better brose the English pages > for more actual information ? > > Its exciting that the project has come such a long way, and IMO it also > was to the benefit of matroska, the container, that there hasn't been so > much updating lately, for stability reasons. If a project is under heavy > development, compatibility is sometimes a problem. Still, i do hope > there is some revitalization of the menues, and its good to hear that > finally matroska tags are going to be used. Yeah I totally forgot that Sergey ported DvdMenuXtractor to Qt4 and it now builds in Windows, OS X and Linux. I still haven't had a chance to work on it though. We're planning to add menu support in CorePlayer sometime in the future so it will probably happen at the same time. Steve From Kazemaini at mapna.com Tue May 8 17:11:53 2007 From: Kazemaini at mapna.com (Kazemaini, Mohammad) Date: Tue, 8 May 2007 18:41:53 +0330 Subject: [Matroska-general] What should i do with this Message-ID: <0367A7D38FACBB479AEB990FC446916080A507@MAPEXCL.mapna.com> Dear friend I did as you described step by step to convert mkv to DVD using DVDsanat and I always come up with this screen The DVDsanta version is 4.5. Best Regards Mohammad Kazemaini -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: problem.JPG Type: image/jpeg Size: 55251 bytes Desc: problem.JPG URL: From josh at resonance.org Sat May 12 15:18:18 2007 From: josh at resonance.org (Josh Green) Date: Sat, 12 May 2007 15:18:18 +0200 Subject: [Matroska-general] EBML questions Message-ID: <1178975898.16311.41.camel@localhost> Hello, I'm a developer of a format called CRAM which is used for compressing files containing audio and binary (such as MIDI audio instruments, etc). This format isn't really in wide use yet, but we're currently polishing things up to advertise it more as an alternative to some other proprietary means of instrument compression. We choose EBML as the basis for this format and have a couple questions concerning some parts of the spec which we're not following. The CRAM format is not using CRC32 currently for level 1 chunks. While we are considering using this for the EBML chunk itself, we don't think it makes sense to use it for the rest of the compressed data, since MD5 is used for the compressed audio and binary data (2 signatures for uncompressed audio and binary). We aren't currently using some of the other chunks marked as Mandatory in the spec. For example EBMLMaxIDLength and EBMLMaxSizeLength. This format is targeted more at compression than streaming, although the sample data itself may be streamed (WavPack or FLAC compressed data), this likely won't be across EBML chunk boundaries. My questions are mainly in regards to developers possibly using other EBML parsing implementations for CRAM. Would not following the above components of the EBML spec, lead to existing parsers failing to parse CRAM? Perhaps this is a non-issue anyways, since not knowing the document type of an EBML file isn't very useful (the contents of the chunks are unknown). We are currently breaking backwards compatibility with the CRAM spec due to some other reasons, so I'd like to get things right this time :) Thanks for any comments on this. Best regards, Josh Green http://cram.resonance.org From steve.lhomme at free.fr Sat May 12 21:03:01 2007 From: steve.lhomme at free.fr (Steve Lhomme) Date: Sat, 12 May 2007 21:03:01 +0200 Subject: [Matroska-general] EBML questions In-Reply-To: <1178975898.16311.41.camel@localhost> References: <1178975898.16311.41.camel@localhost> Message-ID: <46460F65.1040101@free.fr> Josh Green wrote: > Hello, I'm a developer of a format called CRAM which is used for > compressing files containing audio and binary (such as MIDI audio > instruments, etc). This format isn't really in wide use yet, but we're > currently polishing things up to advertise it more as an alternative to > some other proprietary means of instrument compression. Hi, sounds like a good idea :) > We choose EBML as the basis for this format and have a couple questions > concerning some parts of the spec which we're not following. Well, the rest of the email doesn't have questions, but I'll answer them anyway ;) > The CRAM format is not using CRC32 currently for level 1 chunks. While > we are considering using this for the EBML chunk itself, we don't think > it makes sense to use it for the rest of the compressed data, since MD5 > is used for the compressed audio and binary data (2 signatures for > uncompressed audio and binary). CRC32 can be used at all levels and it's never mandatory, so it's fine not to use it. > We aren't currently using some of the other chunks marked as Mandatory > in the spec. For example EBMLMaxIDLength and EBMLMaxSizeLength. As long as the IDs are not longer than 4 bytes long existing parsers should have no problem. And the EBML coded size should not exceed 8 bytes. In general in the EBML specs (like here http://www.matroska.org/technical/specs/) there are some default values. So if you don't set the value in the file (and the value is mandatory) you can assume the default value instead. The goal is not to write obvious value and save space. So in your case that's very good to use default values. > This format is targeted more at compression than streaming, although the > sample data itself may be streamed (WavPack or FLAC compressed data), > this likely won't be across EBML chunk boundaries. My questions are > mainly in regards to developers possibly using other EBML parsing > implementations for CRAM. Would not following the above components of > the EBML spec, lead to existing parsers failing to parse CRAM? Perhaps > this is a non-issue anyways, since not knowing the document type of an > EBML file isn't very useful (the contents of the chunks are unknown). You mean you don't set a DocType ? I think you should do that, because the default value is "matroska" and thus your files will be treated like matroska in many apps. > We are currently breaking backwards compatibility with the CRAM spec due > to some other reasons, so I'd like to get things right this time :) OK. BTW what library do you use to write your files ? libebml ? something you made yourself ? Steve From josh at resonance.org Sun May 13 15:48:19 2007 From: josh at resonance.org (Josh Green) Date: Sun, 13 May 2007 15:48:19 +0200 Subject: [Matroska-general] EBML questions In-Reply-To: <46460F65.1040101@free.fr> References: <1178975898.16311.41.camel@localhost> <46460F65.1040101@free.fr> Message-ID: <1179064099.9705.19.camel@localhost> On Sat, 2007-05-12 at 21:03 +0200, Steve Lhomme wrote: > Josh Green wrote: > > Hello, I'm a developer of a format called CRAM which is used for > > compressing files containing audio and binary (such as MIDI audio > > instruments, etc). This format isn't really in wide use yet, but we're > > currently polishing things up to advertise it more as an alternative to > > some other proprietary means of instrument compression. > > Hi, sounds like a good idea :) > I think so too. It can be a real bummer when a bunch of free instrument files are left compressed with some proprietary format that is less accessible on other operating systems, or the company goes out of business (sfpack for example). > Well, the rest of the email doesn't have questions, but I'll answer them > anyway ;) > Yes I realized they weren't really questions, but more just wanting to get clarification that I'm not doing something particularly wrong with the EBML format ;) > > This format is targeted more at compression than streaming, although the > > sample data itself may be streamed (WavPack or FLAC compressed data), > > this likely won't be across EBML chunk boundaries. My questions are > > mainly in regards to developers possibly using other EBML parsing > > implementations for CRAM. Would not following the above components of > > the EBML spec, lead to existing parsers failing to parse CRAM? Perhaps > > this is a non-issue anyways, since not knowing the document type of an > > EBML file isn't very useful (the contents of the chunks are unknown). > > You mean you don't set a DocType ? I think you should do that, because > the default value is "matroska" and thus your files will be treated like > matroska in many apps. > No, we do set our own DocType, DocTypeVersion and DocTypeReadVersion fields (what I had meant was that if software isn't familiar with the DocType, there isn't a way to interpret the contents of custom EBML chunks). There will be 3 types, "CRAM" for a lossless compressed file, "CRAML" for a lossy compressed file and "CRAMC" for the hybrid correction file (when combined with the matching CRAML results in the original lossless file). All that hybrid stuff thanks to Wavpack :) I noticed that Matroska files have the DocType as the first field in the EBML chunk. I think we should also have our DocType there (currently its after the EBMLVersion and EBMLReadVersion), to ease file identification. > > We are currently breaking backwards compatibility with the CRAM spec due > > to some other reasons, so I'd like to get things right this time :) > > OK. > > BTW what library do you use to write your files ? libebml ? something > you made yourself ? > The current CRAM implementation is part of libInstPatch (http://libinstpatch.resonance.org). We have our own routines for handling the EBML, although its really not too complicated to begin with. It would be good to verify that CRAM is parsable by other implementations such as libebml. One of the reasons we are breaking backwards compatibility, was because I had falsely assumed before that all integers (even values in fields) were stored variable length encoded. After looking over a matroska file with a hex editor, I realized that it isn't even necessary, since the size can already be inferred from the EBML chunk. *So embarrassed* That of course wouldn't have happened if I was using something like libebml. Fortunately CRAM really isn't widely (if at all?) used yet. Anyone who is interested though in instrument files such as SoundFont and GigaSampler, might want to check out one of our side projects: http://sounds.resonance.org Its a staging area for CRAM right now, so its not quite yet ready for use, but will be after the pending release of CRAM format version 4. > Steve > Thank you very much for the responses, helps give me some confidence in the current specification. Best regards! Josh From steve.lhomme at free.fr Mon May 14 13:40:29 2007 From: steve.lhomme at free.fr (Steve Lhomme) Date: Mon, 14 May 2007 13:40:29 +0200 Subject: [Matroska-general] EBML questions In-Reply-To: <1179064099.9705.19.camel@localhost> References: <1178975898.16311.41.camel@localhost> <46460F65.1040101@free.fr> <1179064099.9705.19.camel@localhost> Message-ID: <46484AAD.6030009@free.fr> Josh Green wrote: > I noticed that Matroska files have the DocType as the first field in the > EBML chunk. I think we should also have our DocType there (currently > its after the EBMLVersion and EBMLReadVersion), to ease file > identification. Well, a good code should not have problems with the position. But it's surely safer to mimick matroska in that case. >>> We are currently breaking backwards compatibility with the CRAM spec due >>> to some other reasons, so I'd like to get things right this time :) >> OK. >> >> BTW what library do you use to write your files ? libebml ? something >> you made yourself ? >> > > The current CRAM implementation is part of libInstPatch > (http://libinstpatch.resonance.org). We have our own routines for > handling the EBML, although its really not too complicated to begin > with. It would be good to verify that CRAM is parsable by other > implementations such as libebml. One of the reasons we are breaking > backwards compatibility, was because I had falsely assumed before that > all integers (even values in fields) were stored variable length > encoded. After looking over a matroska file with a hex editor, I > realized that it isn't even necessary, since the size can already be > inferred from the EBML chunk. *So embarrassed* That of course wouldn't > have happened if I was using something like libebml. Fortunately CRAM > really isn't widely (if at all?) used yet. If you want to try the implementation of your files you could pass the file in mkvinfo (in mkvtoolnix). I think alexnoe also coded an EBML tree browser in AVIMuxGUI (http://www.alexander-noe.com/video/amg/) (see "hex viewer for EBML/RIFF tree"). And you can also try to load your files in VLC (VideoLan Client) or in Media Player Classic to see if they assume the files are matroska and fail to read them. Steve From DreamsOfLight at netcabo.pt Mon May 14 02:11:11 2007 From: DreamsOfLight at netcabo.pt (DreamsOfLight) Date: Mon, 14 May 2007 01:11:11 +0100 Subject: [Matroska-general] Convert Message-ID: Hi.Im sending this mail because i have a doubt.I dont know how to convert mkv files to avi files.I have a program to do that but i dont know how to work with that program.Please can you help me?Can you give some hints or indicate a proper program to convert mkv files?I will be waiting for an answer.Thanks for your time. -------------- next part -------------- An HTML attachment was scrubbed... URL: From josh at resonance.org Sat May 19 11:17:26 2007 From: josh at resonance.org (Josh Green) Date: Sat, 19 May 2007 11:17:26 +0200 Subject: [Matroska-general] EBML questions In-Reply-To: <46484AAD.6030009@free.fr> References: <1178975898.16311.41.camel@localhost> <46460F65.1040101@free.fr> <1179064099.9705.19.camel@localhost> <46484AAD.6030009@free.fr> Message-ID: <1179566246.9576.14.camel@localhost> On Mon, 2007-05-14 at 13:40 +0200, Steve Lhomme wrote: > Josh Green wrote: > > I noticed that Matroska files have the DocType as the first field in the > > EBML chunk. I think we should also have our DocType there (currently > > its after the EBMLVersion and EBMLReadVersion), to ease file > > identification. > > Well, a good code should not have problems with the position. But it's > surely safer to mimick matroska in that case. > > >>> We are currently breaking backwards compatibility with the CRAM spec due > >>> to some other reasons, so I'd like to get things right this time :) > >> OK. > >> > >> BTW what library do you use to write your files ? libebml ? something > >> you made yourself ? > >> > > > > The current CRAM implementation is part of libInstPatch > > (http://libinstpatch.resonance.org). We have our own routines for > > handling the EBML, although its really not too complicated to begin > > with. It would be good to verify that CRAM is parsable by other > > implementations such as libebml. One of the reasons we are breaking > > backwards compatibility, was because I had falsely assumed before that > > all integers (even values in fields) were stored variable length > > encoded. After looking over a matroska file with a hex editor, I > > realized that it isn't even necessary, since the size can already be > > inferred from the EBML chunk. *So embarrassed* That of course wouldn't > > have happened if I was using something like libebml. Fortunately CRAM > > really isn't widely (if at all?) used yet. > > If you want to try the implementation of your files you could pass the > file in mkvinfo (in mkvtoolnix). I think alexnoe also coded an EBML tree > browser in AVIMuxGUI (http://www.alexander-noe.com/video/amg/) (see "hex > viewer for EBML/RIFF tree"). And you can also try to load your files in > VLC (VideoLan Client) or in Media Player Classic to see if they assume > the files are matroska and fail to read them. > > Steve > Hello Steve, I think at this point we have actually decided to use the CRC-32 for some smaller information chunks, where it would be good to know if there is something corrupted (file names for example). The issue now is knowing how to use the CRC-32 ([BF] chunk). I see 3 seemingly conflicting definitions of this: http://www.matroska.org/technical/specs/ http://ebml.sourceforge.net/specs/ http://www.matroska.org/technical/specs/rfc/index.html I am assuming the 1st is likely the correct one. In other words: the CRC-32 chunk can appear anywhere in a master containing chunk and applies to all data within that chunk. At least that is how we are planning on using it. Thanks again for the clarifications. Josh Green From ianfancourtm32 at ntlworld.com Sun May 20 16:03:13 2007 From: ianfancourtm32 at ntlworld.com (Ian) Date: Sun, 20 May 2007 15:03:13 +0100 Subject: [Matroska-general] MKV codec on vista Message-ID: do you have a codec that i can install on windows vista to support playing mkv files? cheers ian -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at matroska.org Wed May 23 15:55:32 2007 From: chris at matroska.org (Christian HJ Wiesner) Date: Wed, 23 May 2007 15:55:32 +0200 Subject: [Matroska-general] New usage for MKV : Mux VC1 HD video tracks into MKV Message-ID: <465447D4.40305@matroska.org> Hi, a new potential use for MKV is getting very nice attention lately : http://forum.doom9.org/showthread.php?t=121497&highlight=matroska Regards Christian From gundam1965 at msn.com Tue May 29 03:29:13 2007 From: gundam1965 at msn.com (Supreme Gunman) Date: Mon, 28 May 2007 19:29:13 -0600 Subject: [Matroska-general] im stupid and need help Message-ID: ok, so i downloaded the CCCP-Insurgent-2007-01-01 file, but how do i install it. it tells me its not installed, but not what to do. can you help? _________________________________________________________________ PC Magazine?s 2007 editors? choice for best Web mail?award-winning Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507