mkvtoolnix: new version

[bond]

to my knowledge a .m4a file from itunes is just a .mp4 file with changed extension (to be able to distinguish audio from video files) nothing less, nothing more

i think it would be better to tell everyone to rename their m4a files to mp4 instead of supporting it, we must get rid of this ugly, apple self-made extension

[Demi-god]

I didn't realize there were already "Options that only apply to VobSub subtitle tracks" Does sub+idx already work in MKV?



No, it's deactivated Activating it and getting it right won't be a problem, but there still ain't a playback filter that's able to play VobSubs in mkv.

So everything at this point depends on Gabest making his Matroska Splitter recognise the vobsub tracks in an mkv file?

[ChristianHJW]

Originally posted by Demi-god
So everything at this point depends on Gabest making his Matroska Splitter recognise the vobsub tracks in an mkv file?

... even worse ... Toff could update the splitter filter in no time, there is not much to do unless the compressed vobsubs are being used, mainly mapping of the new codec ID to a ( not existing, still to be defined ) GUID, but we need Gabest to update vsfilter.dll so it can understand vobsub if they are NOT being read from an external file, but were embedded in a MKV ( or whatever ) file ...

[Demi-god]

there is not much to do unless the compressed vobsubs are being used, mainly mapping of the new codec ID to a ( not existing, still to be defined ) GUID

Pardon my impatience, but is something preventing this from being done? Or is this something that Gabest needs to do in vsfilter.dll? Is the Matroska part ready to roll?

[Atamido]

Originally posted by Demi-god
Pardon my impatience, but is something preventing this from being done? Or is this something that Gabest needs to do in vsfilter.dll?

Originally posted by ChristianHJW
...but we need Gabest to update vsfilter.dll so it can understand vobsub if they are NOT being read from an external file...

Is this what you were asking?

[Liisachan]

Originally posted by bond
to my knowledge a .m4a file from itunes is just a .mp4 file with changed extension (to be able to distinguish audio from video files) nothing less, nothing more

That's what Audio Coding Wiki says, but there's more to it, at least for mp4UI:

(1) mp4UI 0.9.5 can extract AAC (ADTS) from aac files created by PsyTEL, QcuikTime, Nero, FAAC.
(2) mp4UI 0.9.5 can NOT extract AAC (ADTS) from aac files created by iTuens.

Now, I think this is mp4UI's problem. I found that iTunes' files do have ADTS headers (periodical FF F1 [or FF F9 for MPEG-2 AAC]...), tho the period seems longer than usual. Plus, mp4creator60 0.9.8 can extract AAC from iTunes' file. So they are "normal" after all. That's it. Sorry for the mess.
Just extended filemask for "m4a" would be enough.

Originally posted by bond
i think it would be better to tell everyone to rename their m4a files to mp4 instead of supporting it, we must get rid of this ugly, apple self-made extension

Well, foobar2000's FAAC plugin can create files with the extension m4a too. the extension itself is nothing new, and actually it's practical to distinguish mp4 audio files from mp4 movie files by extensions, unless you're using the same player for both.

As a side note, "m4a" was once proposed for "Matroska for Audio" which is now called "MKA"... It was obvious that Matroska couldn't use it, because it was already treated as an extension for MPEG-4 Audio back then.

[Demi-god]

Is this what you were asking?

I wanted to know if Gabest is the only thing holding back the ability to mux vobsub subtitles into mkv files, or if the Matroska folks need to do something that they can do independent of Gabest, or if they need to specify something in coordination with Gabest.

[Atamido]

Gabest needs to add the support into VSFilter. After that is done the proper GUID can be added to the splitter filter.

[ChristianHJW]

Originally posted by Demi-god I wanted to know if Gabest is the only thing holding back the ability to mux vobsub subtitles into mkv files, or if the Matroska folks need to do something that they can do independent of Gabest, or if they need to specify something in coordination with Gabest.

Yes, we are waiting for Gabest only. Mosu can mux vobsub fine, and the files play in mplayer on Linux ...

[RathO]

Gabest, wherever you are, the community needs you back!
(And the files sleeping on my computer waiting for subs to be muxed to mkv too!)

Regards

[Liisachan]

1. Question about mkvmerge:

I'd like to use --title "Title not in English" and am wondering which encoding I can use for "Title not in English"
For instance, would this work? (I'm afraid I don't think so)

@rem .bat in UTF8
mkvmerge -o out.mkv in.mkv --title "Something in UTF8"

2. I think I can use a chapters in UTF-8, but mkvinfo 0.7.2 cannot read it so nicely. For instance,

mkvinfo chapter_in_japanese.mkv > test.txt

gave me something like this:

|+ Chapters
| + Edition entry
| + Chapter atom
| + UID: 3967978330
| + Start: 00:00:00.000
| + Display
| + String: oooooooooFOURCC
| + Language: jpn

Where "ooooooooo" is a correct (but incomplete) part of the string, and "FOURCC" is not a part of the string, but a buggy output.

[Mosu]

Originally posted by Liisachan
1. Question about mkvmerge:

I'd like to use --title "Title not in English" and am wondering which encoding I can use for "Title not in English"
For instance, would this work? (I'm afraid I don't think so)

@rem .bat in UTF8
mkvmerge -o out.mkv in.mkv --title "Something in UTF8"

Correct. --title (just like --track-name) uses the system's current locale for conversion to UTF-8. I probably should add yet another charset parameter that would apply to all command line arguments - that would fix it for you.

2. I think I can use a chapters in UTF-8, but mkvinfo 0.7.2 cannot read it so nicely. For instance,

mkvinfo chapter_in_japanese.mkv > test.txt

gave me something like this:

|+ Chapters
| + Edition entry
| + Chapter atom
| + UID: 3967978330
| + Start: 00:00:00.000
| + Display
| + String: oooooooooFOURCC
| + Language: jpn

Where "ooooooooo" is a correct (but incomplete) part of the string, and "FOURCC" is not a part of the string, but a buggy output.

Very interesting. If you still have the original chapter file, could you please send that one to me and tell me which charset they're in?

[Liisachan]

sent

Mkvextract gets the chapter info correctly,
so I believe muxing is ok, and it's just a small problem in mkvinfo
(hope so)

Here's a pic to show what i mean:
http://mion.wisnet.ne.jp/mkvinfo.png

[Mosu]

Originally posted by Liisachan
sent

Mkvextract gets the chapter info correctly,
so I believe muxing is ok, and it's just a small problem in mkvinfo
(hope so)

Here's a pic to show what i mean:
http://mion.wisnet.ne.jp/mkvinfo.png

Thanks. Unfortunately I cannot reproduce this - I get 'abcdefg' (normal output). For true multi byte strings mkvinfo might always output garbage because it cannot handle wide strings, and that will probably be like it for the foreseeable future.

Anyway, I've added a new option, '--command-line-charset'. With it you can set the charset that is used in the conversion to UTF-8 for strings given on the command line. It applies to the '--title' (mmg: "segment title", global tab), '--track-name' (mmg: "track name", input tab) and '--attachment-description' options. It can be set in mmg on the global tab.

This way you can have your batch file in UTF-8 like this:

@rem .bat in UTF-8

mkvmerge -o output.mkv input.avi --title 'something with UTF-8 coded characters' --command-line-charset UTF-8

The placement of this option is not important.

If you want to give it a try then download http://www.bunkus.org/videotools/mkv...20031025-2.rar

Thanks

(Note to the others: Yes, this version does contain full support for VobSubs Although there's still no filter for Windows that can handle them.)

Toff could update the splitter filter in no time

It this only related to vobsub inside MKV or does it apply also to working audio-stream-names in mkv?

That's really the only thing why I don't move from OGM to MKV, the vobsub-inside-mkv would be nice too, but external subs are working as well, whereas audio-stream-names are NOT working at all.

Since MKV supports chapter-jumps to not-key-frames - impossible with OGM - I would really like to switch, so please check this audio-stream-problem ASAP.

Thanks
Raist

[ChristianHJW]

Copied from IRC :

<ChristianHJW> Toff : http://forum.doom9.org/showthread.ph...623#post390623
<Toff> i already updated the filter for that
<Toff> (even if there is a bug )
<Toff> (which is fixed here, but not yet sent to Gabest)
* Animaniac has joined #matroska
<ChristianHJW> Toff : tell him ... he may make his next rip in MKV already ... one saved soul

....

Thanks for that info!

Raist

[Liisachan]

Originally posted by Mosu
Thanks. Unfortunately I cannot reproduce this - I get 'abcdefg' (normal output).

I get "abcdefg" too if I set "language for non-unicode programs" = "English" This can be actually another problem
because the string is not abcdefg but &#xff41;&#xff42;(U+FF41 U+FF42)...

anyway the first problem is not fixed in this newest beta, as long as I'm in the same mode (language for non-unicode programs = japanese)

Anyway, I've added a new option, '--command-line-charset'. With it you can set the charset that is used in the conversion to UTF-8 for strings given on the command line. It applies to the '--title' (mmg: "segment title", global tab), '--track-name' (mmg: "track name", input tab) and '--attachment-description' options. It can be set in mmg on the global tab.

This does work sometimes, but not always.
Let's just think about '???????' where the single quotation mark = 0x27, but there can be 0x27 in ???? thanks to U+27xx and U+xx27. This way, this can't work in UTF-16, and the same goes for some other encodings.
Another confusing problem is, Windows is meddling when it passes a string input/output, to/from mkvmerge...it'll convert charset by itself (in a lossy way, for instance ä will be converted to a if the codepage=japanese, and one Kanji will be converted to 2 meaningless alphabets if the codepage!=japanese)...plus you should hack the clipboard encoding if you'd like to enable one to paste something in unicode into the editbox in mmg...otherwise, windows defaults the clipboard encoding to "Lanugage for non-unicode program"
so...probably the safest way is not very cool:

--title @somefile.utf8.txt

This way you can have your batch file in UTF-8 like this:

@rem .bat in UTF-8

mkvmerge -o output.mkv input.avi --title 'something with UTF-8 coded characters' --command-line-charset UTF-8

Hmmm, in a bat file? well, utf-8 could be possible, but utf-16 will be impossible this way (in bat) because cmd.exe can't find mkvmerge as it'd think the command line would be "m k v m e r g e"

BUT, more importantly,,,,,,, finally SUB+IDX is coming!!

Here's a cosmetic thing:
i suppose "Subtitle charset" list in mmg should be disabled if the track is S_VOBSUB

[alx]

Sorry to bother you ppl, but recently i want to mux an rmvb file with an mp3 file and this message appears in mmg.exe

Warning: real_reader: packet assembly failed. Expected packet length was 54842 but found only 1 sub packets containing 47372 bytes. Sub packet number: 316160. Trying to continue.
Warning: real_reader: G:\zzzdvd1\1.rmvb: Data packet length is too small: 0. Other values: object_version: 0x2091, id: 0x1222, timecode: 100, flags: 0x5f. File position: 651304067. Aborting this file.

The .mkv file was truncated, but when i play the rmvb file its ok, and the same happens when i play the .mp3 file

Any ideas why this happend¿?
Sorry for my poor english.
Alx.

[Mosu]

Originally posted by alx
Warning: real_reader: packet assembly failed. Expected packet length was 54842 but found only 1 sub packets containing 47372 bytes. Sub packet number: 316160. Trying to continue.

This means that the packet stream is missing some packets.

Warning: real_reader: G:\zzzdvd1\1.rmvb: Data packet length is too small: 0. Other values: object_version: 0x2091, id: 0x1222, timecode: 100, flags: 0x5f. File position: 651304067. Aborting this file.

This means that the file in question is damaged and that mkvmerge cannot recover from this error. Thank Real for a container without any syncword.

Without having the file in question I can't say if this could be processed completely, but I doubt it. Maybe RealPlayer has some strange error recovery method that I just can't think of.