View Full Version : mkvtoolnix (Matroska toolkit): new release
Pages :
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
[
16]
17
18
19
20
niamh
14th June 2004, 19:41
Lemme get this straight - the official 0.9.1 uses less CPU than a pre-build BEFORE 0.9.1
no, after :)(I keep picking up the updates but I've lost track of which I had exactly, the latest or the last but one). Let me get the very latest update and run it all again. I'll give you times too :)
thana
14th June 2004, 20:28
Originally posted by Mosu
That's a feature (no really!). mkvmerge will only try to extract the aspect ratio from the MPEG4 bitstream if the user hasn't specified anything on the command line. You've explicitely overridden the aspect ratio, so mkvmerge won't even look for it.
No, i didn't. i let mkvmerge pick it up from the bitstream, and it works correctly. the only difference between the newest build and the older ones is, that with the newer ones it isn't mentioned in the log anymore (that it found the AR and applied it to mkv). but its really no big thing, i just thought i mention it because it changed it the latest build.
niamh
14th June 2004, 20:29
(same files for all of them, same output, i just press ok and remux the same stuff over:
RAM usage is the same for all builds no bother 6800>7500 k in the same places
official build:
cpu:25/35>50, 62 seconds
30/40->55, 49 seconds
30/40>50, 57 seconds
30/40>50, 55 seconds
-build20040613-1:
30/40>60, 57 seconds
30/45>55, 54/ 55/ 59 seconds
45/50 (forgot to note down the time grrr)
-build20040614-1:
20/35>50, 60 seconds
30/40>50, 54/ 55 seconds
35/50>55, 53 seconds
and the oddball:
45/55>70-80 with a 98% peak!, 44 seconds
So, no, in general it doesn't look like there is a difference..though build ..14.1 gave me one weird result for sure.
Mosu
14th June 2004, 20:44
Originally posted by niamh
So, no, in general it doesn't look like there is a difference..though build ..14.1 gave me one weird result for sure.
Yeah, I'd call those results inconclusive (meaning there's no obvious difference between the builds). But thanks for testing :)
Mosu
14th June 2004, 20:48
Originally posted by thana
than i tried to play it, and at first it worked normally, but after i came past the 2GB mark of the input avi, all dshow-players display garbage and finally crash.
This new build should fix that > 2GB problem (at least it does work with the file you provided including playback). Please test it. Thanks.
http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-0.9.1-build20040614-2.rar
thana
14th June 2004, 23:01
yes i can confirm i works. no problems found so far. good work :)
niamh
14th June 2004, 23:25
It's sort of even conclusive towards the fact that there is no difference :D.
thana
15th June 2004, 14:36
ok, time for some new bugreports (i'm getting quite good at finding them it seems ;))
it looks like the problem with the chunk-before-first-mp3-header was not fully fixed, after converting an avi with two mp3-streams the audio got once more detected as Mpeg1 layer1 (in the shell ext.), and the splitter crashes when i try to play the mkv. i extracted the mp3 from the avi, and when i try to import it into the latest build i get this:mkvmerge -i failed. Return code 2. Error: File has unknown type. v0.9.0 crashes right away even without error.
i already uploaded it as usual (crash.mp3).
and another problem that is probably related: after converting another dual-audio avi the audio-tracks got heavily async. here's the log:
mkvmerge v0.9.1, built on Jun 14 2004 21:43:34
'X:\Futurama.avi': Using the AVI demultiplexer. Opening file. This may take some time depending on the file's size.
'X:\Futurama.avi' track 0: Using the video output module for the video track.
'X:\Futurama.avi' track 1: Using the MPEG audio output module.
'X:\Futurama.avi' track 2: Using the MPEG audio output module.
Opened 'g:\test.mkv' for writing.
The MPEG audio track 1 from 'X:\Futurama.avi' contained 128 bytes of garbage at the beginning. This corresponds to a delay of 7ms. This delay will be used instead of the garbage data.
Warning: The MPEG audio track 1 from 'X:\Futurama.avi' contained 14 bytes of garbage at the beginning which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'X:\Futurama.avi' contained 20 bytes of garbage at the beginning which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'X:\Futurama.avi' contained 280 bytes of garbage at the beginning which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'X:\Futurama.avi' contained 79 bytes of garbage at the beginning which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'X:\Futurama.avi' contained 106 bytes of garbage at the beginning which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'X:\Futurama.avi' contained 85 bytes of garbage at the beginning which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'X:\Futurama.avi' contained 99 bytes of garbage at the beginning which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'X:\Futurama.avi' contained 85 bytes of garbage at the beginning which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'X:\Futurama.avi' contained 99 bytes of garbage at the beginning which were skipped. The audio/video synchronization may have been lost.
The MPEG audio track 2 from 'X:\Futurama.avi' contained 399 bytes of garbage at the beginning. This corresponds to a delay of 39ms. This delay will be used instead of the garbage data.
Warning: The MPEG audio track 1 from 'X:\Futurama.avi' contained 85 bytes of garbage at the beginning which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'X:\Futurama.avi' contained 99 bytes of garbage at the beginning which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'X:\Futurama.avi' contained 85 bytes of garbage at the beginning which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'X:\Futurama.avi' contained 99 bytes of garbage at the beginning which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'X:\Futurama.avi' contained 85 bytes of garbage at the beginning which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'X:\Futurama.avi' contained 99 bytes of garbage at the beginning which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'X:\Futurama.avi' contained 85 bytes of garbage at the beginning which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'X:\Futurama.avi' contained 99 bytes of garbage at the beginning which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'X:\Futurama.avi' contained 85 bytes of garbage at the beginning which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'X:\Futurama.avi' contained 99 bytes of garbage at the beginning which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'X:\Futurama.avi' contained 85 bytes of garbage at the beginning which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'X:\Futurama.avi' contained 99 bytes of garbage at the beginning which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'X:\Futurama.avi' contained 85 bytes of garbage at the beginning which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'X:\Futurama.avi' contained 99 bytes of garbage at the beginning which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'X:\Futurama.avi' contained 85 bytes of garbage at the beginning which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'X:\Futurama.avi' contained 99 bytes of garbage at the beginning which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'X:\Futurama.avi' contained 85 bytes of garbage at the beginning which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'X:\Futurama.avi' contained 99 bytes of garbage at the beginning which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'X:\Futurama.avi' contained 85 bytes of garbage at the beginning which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'X:\Futurama.avi' contained 99 bytes of garbage at the beginning which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'X:\Futurama.avi' contained 85 bytes of garbage at the beginning which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'X:\Futurama.avi' contained 99 bytes of garbage at the beginning which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'X:\Futurama.avi' contained 85 bytes of garbage at the beginning which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'X:\Futurama.avi' contained 99 bytes of garbage at the beginning which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'X:\Futurama.avi' contained 85 bytes of garbage at the beginning which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'X:\Futurama.avi' contained 99 bytes of garbage at the beginning which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'X:\Futurama.avi' contained 85 bytes of garbage at the beginning which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'X:\Futurama.avi' contained 99 bytes of garbage at the beginning which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'X:\Futurama.avi' contained 85 bytes of garbage at the beginning which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'X:\Futurama.avi' contained 99 bytes of garbage at the beginning which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'X:\Futurama.avi' contained 85 bytes of garbage at the beginning which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'X:\Futurama.avi' contained 64 bytes of garbage at the beginning which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'X:\Futurama.avi' contained 42 bytes of garbage at the beginning which were skipped. The audio/video synchronization may have been lost.
progress: 117/32595 frames (0%)
[...]
progress: 32595/32595 frames (100%)
Writing cue entries (the index)...
Muxing took 66 seconds.i thought when you try to compensate for garbage at the beginning you might as well get it right so it stays in sync every time even after sync is lost. should i upload this mp3 too, or better the complete avi (only 175Mb this time)?
JasonFly
15th June 2004, 17:14
I have a minor problem with the 0.9.0 release. I didn't tested with previous because I never used joblist. The problem concerns joblist and some chars(é,ô,è...)
I have created some settings files and when I opened them in mmg and click "start muxing", the file is created without problems with the rigth chars.
But, when I open this setting file, click add to job queue and then I start the Job, mmg fails or create a file with a strange name(cut from the "é", or "ô" char). TITLE information inside the mkv is also wrong.
That seems very srtange to me since my settings files work when I don't use the joblist.
Mosu
15th June 2004, 17:18
Originally posted by JasonFly
I have a minor problem with the 0.9.0 release. I didn't tested with previous because I never used joblist. The problem concerns joblist and some chars(é,ô,è...)
Fixed in 0.9.1.
JasonFly
15th June 2004, 17:30
Thanks. And sorry to not have seen this before in the changelog.
Mosu
15th June 2004, 18:20
Originally posted by JasonFly
Thanks. And sorry to not have seen this before in the changelog.
No problem :)
Mosu
15th June 2004, 22:40
Originally posted by thana
it looks like the problem with the chunk-before-first-mp3-header was not fully fixed, after converting an avi with two mp3-streams the audio got once more detected as Mpeg1 layer1 (in the shell ext.), and the splitter crashes when i try to play the mkv.
Thanks. Please test http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-0.9.1-build20040615-1.rar
thana
16th June 2004, 14:01
Originally posted by Mosu
Thanks. Please test http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-0.9.1-build20040615-1.rar
ok, we are making progress! most of my files mux correctly now, only a few more are left where one audio-stream is still detected as MPEG1 Layer1 (and crash the splitter). This time mkvmerge gives no error when importing, but shows the audio track type as MPEG1 Layer1. the extracted mp3 is uploaded as usual (crash2.mp3).
and i have good news regarding the garbage-to-delay-compensation: i've remuxed ~70 problem-files with the new build and they all stay 100% in sync! great work, thx!
Emp3r0r
16th June 2004, 17:43
Mosu: can mmg automatically create the output name as it does now but do it anytime the input file changes. As of now, everytime I want to mux a few avi files into mkv files I have to close and reopen mmg for each file to automatically set the output name. (I know, I'm lazy)
Thanks
Mosu
16th June 2004, 18:20
Originally posted by Emp3r0r
Mosu: can mmg automatically create the output name as it does now but do it anytime the input file changes. As of now, everytime I want to mux a few avi files into mkv files I have to close and reopen mmg for each file to automatically set the output name. (I know, I'm lazy)
Thanks
File -> New
Mosu
16th June 2004, 19:19
Originally posted by thana
ok, we are making progress! most of my files mux correctly now, only a few more are left where one audio-stream is still detected as MPEG1 Layer1 (and crash the splitter).
Thanks, try http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-0.9.1-build20040616-1.rar
and i have good news regarding the garbage-to-delay-compensation: i've remuxed ~70 problem-files with the new build and they all stay 100% in sync! great work, thx!
Great to hear :) Thanks for the feedback.
thana
16th June 2004, 21:57
Originally posted by Mosu
Thanks, try http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-0.9.1-build20040616-1.rar
works perfect! no more problems i could think of! (well, at least not for the moment ;)). i wish every opensource/freeware-author would be as responsive and fast in fixing bugs as you are. thx very much!
Mosu
16th June 2004, 22:02
Originally posted by thana
works perfect! no more problems i could think of! (well, at least not for the moment ;)). i wish every opensource/freeware-author would be as responsive and fast in fixing bugs as you are. thx very much!
Thanks to you for testing, providing comprehensive and reproducable bug reports, for providing test files etc. It makes life much easier for me that way ;)
pixolex
17th June 2004, 00:19
Originally posted by Mosu
I think I've found out why it doesn't work. The problem was that you had non-ASCII characters in your file names, and unlike the 'main' mux handling this was broken in the job handling. So please download and test this new build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-0.9.0-build20040613-1.rar
Thanks it works now! bug fixed!
sugestion:
When hiting the botton ADD TO JOB QUEUE the name for the job should be automaticaly set...(it's easear)...the name of the file it's good for me...but the output file name edited not the name of the input file seted automaticaly...do you understand :)
Other...:rolleyes:
i know that in the job queue it's not important the name of the job because tou use ID number...but some times when we make many episodes it normal to repeat episodes...it is possible to show a warning if the jobname is duplicated?
Edit:
Other problem when always on top is selected, after start processing the jobs it's not possible to disable always on top or minimize the windows...
pixolex
17th June 2004, 01:13
Originally posted by Mosu
Thanks to you for testing, providing comprehensive and reproducable bug reports, for providing test files etc. It makes life much easier for me that way ;)
It's very bad to escape from your responsabilities...:D
"would be as responsive and fast in fixing bugs as you are" IT'S TRUE don't be modest...
Once again THANKS !
Liisachan
18th June 2004, 13:17
Thanks again and always for your nifty tools.
I have a question. Are there any easy ways to achive (key)frame-accurate splitting of MKV, when VDM cannot do it because of some reason, like the file has S_VOBSUB tracks?
I'm wondering if it'd be easy for you to update mkvmerge a little bit so that it will accept not only −−split <HH:MM:SS>
but −−split <HH:MM:SS.mmm> where .mmm is for milliseconds......
Tyia :)
[edit (added)]
When you use --split 00:12:34, the file will be splitted at the first Keyframe after 00:12:34, right? If so, there can be trouble when there happen to be more than one Keyframes between 00:12:34-35, and youd like to use the 2nd or 3rd...keyframe as the splitting point....
thana
18th June 2004, 15:31
some more or less cosmetic stuff:
it looks like the job queue management window has some bugs. when you delete an entry, all entry below that one in the list get deleted too. also when you press the up button to move jobs up in the list, the other jobs get shuffled around randomly.
and i suggest you put some linebreaks into the tooltips for better readability, f.e. the 'cue name format'-tooltip doesn't even fit on a 1280 hor. resolution.
and some positive feedback: the new 'add commandline options' dialog is really great. very easy to handle and the descriptions are really detailed and - uhmm - descriptive ;). with all those new options you can really experiment a lot (especially --engage cow is a real winner ;)).
Mosu
19th June 2004, 20:19
Originally posted by Liisachan
I'm wondering if it'd be easy for you to update mkvmerge a little bit so that it will accept not only −−split <HH:MM:SS>
but −−split <HH:MM:SS.mmm> where .mmm is for milliseconds......
Totally trivial, I'll do that tomorrow (after I'm done with some other ugly wxWidgets issues... grrr!)
[edit (added)]
When you use --split 00:12:34, the file will be splitted at the first Keyframe after 00:12:34, right?
Right, so yes, I do see the need for increased precision.
Mosu
19th June 2004, 20:22
Originally posted by thana
some more or less cosmetic stuff:
it looks like the job queue management window has some bugs.
Bloody hell! This is an issue that only occurs on Windows, that's why I haven't seen it earlier. Nevertheless it also seems to trigger a bug in wxWidgets which I haven't been able to work around yet. I'm compiling wxWidgets 2.5.2 at the moment, maybe it'll behave better.
and i suggest you put some linebreaks into the tooltips for better readability, f.e. the 'cue name format'-tooltip doesn't even fit on a 1280 hor. resolution.
Interesting. Again an issue that only occurs on Windows because with GTK the tooltips are broken up into individual lines automatically. I'll go through all tooltips and insert some newlines. Thanks for noticing.
and some positive feedback: the new 'add commandline options' dialog is really great. very easy to handle and the descriptions are really detailed and - uhmm - descriptive ;). with all those new options you can really experiment a lot (especially --engage cow is a real winner ;)).
:) The descriptions are taken directly from the man page (safe for the --engage stuff - it hasn't been documented before, and no, it's really not meant for the average user. Well, safe for '--engage cow' of course ;))
Mosu
19th June 2004, 22:34
Originally posted by thana
some more or less cosmetic stuff:
it looks like the job queue management window has some bugs. when you delete an entry, all entry below that one in the list get deleted too. also when you press the up button to move jobs up in the list, the other jobs get shuffled around randomly.
Ok, here's my take on it: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-0.9.1-build20040619-1.rar
pixolex
20th June 2004, 02:50
Originally posted by pixolex
Thanks it works now! bug fixed!
sugestion:
When hiting the botton ADD TO JOB QUEUE the name for the job should be automaticaly set...(it's easear)...the name of the file it's good for me...but the output file name edited not the name of the input file seted automaticaly...do you understand :)
Other...:rolleyes:
i know that in the job queue it's not important the name of the job because tou use ID number...but some times when we make many episodes it normal to repeat episodes...it is possible to show a warning if the jobname is duplicated?
Edit:
Other problem when always on top is selected, after start processing the jobs it's not possible to disable always on top or minimize the windows...
don't forget me :(
Mosu
20th June 2004, 08:28
Originally posted by pixolex
don't forget me :(
I won't, don't worry ;)
Mosu
20th June 2004, 09:53
http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-0.9.1-build20040620-2.rar
Originally posted by pixolex
When hiting the botton ADD TO JOB QUEUE the name for the job should be automaticaly set...(it's easear)...the name of the file it's good for me...but the output file name edited not the name of the input file seted automaticaly...do you understand :)
Done. It takes the _filename_ part of the output file name as the default when adding a job to the queue (e.g. it'll use "blah" for "c:\somewhere\over\the\rainbow\blah.mkv").
i know that in the job queue it's not important the name of the job because tou use ID number...but some times when we make many episodes it normal to repeat episodes...it is possible to show a warning if the jobname is duplicated?
Done. It'll only ask for confirmation if the option 'ask before overwriting' on the 'settings' tab is checked.
Other problem when always on top is selected, after start processing the jobs it's not possible to disable always on top or minimize the windows...
Fixed. "Always on top" will be temporarily disabled when the muxing dialog or the job dialog is shown and restored after they've been dismissed.
Mosu
20th June 2004, 09:54
Originally posted by Liisachan
I'm wondering if it'd be easy for you to update mkvmerge a little bit so that it will accept not only −−split <HH:MM:SS>
but −−split <HH:MM:SS.mmm> where .mmm is for milliseconds......
Try http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-0.9.1-build20040620-2.rar please.
Mosu
20th June 2004, 10:23
Originally posted by thana
and i suggest you put some linebreaks into the tooltips for better readability, f.e. the 'cue name format'-tooltip doesn't even fit on a 1280 hor. resolution.
http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-0.9.1-build20040620-3.rar
Liisachan
20th June 2004, 11:13
Originally posted by Mosu
Try http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-0.9.1-build20040620-2.rar please.
Worked. Thank you :D
I made a small xvid vid for testing, with Max I = 6, so that there will be a lot of key frames in each second and tested it several way, trying to split on different keyframes.
Result:
Your tool can now split the vid exactly at any keyframe, no matter how many keyframes is within one second, just by specifying like 00:00:56.389 when the keyframe in question is around 00:00:56.390.
Note:
In this case, VirtualDub says the keyfrmae in question is at 00:00:56.390, but the exact timing might be 56.3896 or something because of rounding error, so specifying 56.389 (one millisec smaller) seems to be a good solution. If the exact timing is 56.3896 and you specify 56.390, i suppose MKVmerge will split the vid at the [i]next[/] keyframe.
Setting 1 ms smaller is harmless at all, because 1 frame is like 30-40 ms anyway...
pixolex
20th June 2004, 12:22
Originally posted by Mosu
http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-0.9.1-build20040620-2.rar
Done. It takes the _filename_ part of the output file name as the default when adding a job to the queue (e.g. it'll use "blah" for "c:\somewhere\over\the\rainbow\blah.mkv").
Done. It'll only ask for confirmation if the option 'ask before overwriting' on the 'settings' tab is checked.
Fixed. "Always on top" will be temporarily disabled when the muxing dialog or the job dialog is shown and restored after they've been dismissed.
Thanks! :) you are the boss! :D
outlyer
20th June 2004, 12:26
Originally posted by Mosu
Well, safe for '--engage cow' of course ;)LMAO, this must be the most hilarious easter egg on earth :D
pixolex
20th June 2004, 13:33
sorry MOSU but...
Now i can't add any job to the queue...the job description is automatically set but when hit OK the job is not added and the window of the job description keep on top...and i have to hit CANCEL?!?!? even if i change the name...:confused:
Mosu
20th June 2004, 13:59
Originally posted by pixolex
sorry MOSU but...
Now i can't add any job to the queue...the job description is automatically set but when hit OK the job is not added and the window of the job description keep on top...and i have to hit CANCEL?!?!? even if i change the name...:confused:
Doh... http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-0.9.1-build20040620-5.rar
thana
20th June 2004, 16:25
i tried the latest build (mkvtoolnix-0.9.1-build20040620-5.rar) and the jobs window seems to work properly now. a possible enhancement for the automatic job description naming: highlight the jobs description after clicking on 'add to job queue', so if you want to give it another name you can just start typing instead of first having to delete the text.
the tooltips do have linebreaks now, but it looks a little bit awkward, like a broken email-client which doesn't support multiple quotes (like outlook express). as an example the tooltip for 'Cue name format' reads like this:mkvmerge can read CUE sheets for
audio cds and automatically
convert
them to chapters. This option
controls
how the chapter names are
created.
The sequence '%p' is replaced by
the track's PERFORMER, the
sequence
'%t' by the track's TITLE, '%n'
by the track's number and '%N'
by the track's number padded with
a leading 0 for track numbers <
10. The rest is copied as is. If
nothing is entered then '%p - %t'
will be used.
Mosu
20th June 2004, 16:36
Originally posted by thana
i tried the latest build (mkvtoolnix-0.9.1-build20040620-5.rar) and the jobs window seems to work properly now. a possible enhancement for the automatic job description naming: highlight the jobs description after clicking on 'add to job queue', so if you want to give it another name you can just start typing instead of first having to delete the text.
Can't do that. I'm using a standard input dialog which I have no control over.
the tooltips do have linebreaks now, but it looks a little bit awkward, like a broken email-client which doesn't support multiple quotes (like outlook express). as an example the tooltip for 'Cue name format' reads like this:
Yes, I know. Guess what: That's either wxWidgets or Windows itself doing some strange ADDITIONAL wrapping. If there's NO \n in the complete tooltip then the stuff is not wrapped at all. If there IS at least one \n (e.g. at the end) then it'll be wrapped - somewhere in the middle into between one and three pretty long lines. The more \n I insert the SHORTER the lines get that... (Again I don't really have control over the whole process, and I have no clue why.) So you'll have to live with that for the time being 'cause I'm tired of fighting against toolkit issues... (This is one of the reasons why I hate writing GUIs in the first place)
thana
20th June 2004, 16:46
Originally posted by Mosu
So you'll have to live with that for the time being...i believe i'm able to do that ;)
(if i had known that this is such a hassle i wouldn't have bugged you about it in the first place, as its really only cosmetics).
Mosu
20th June 2004, 16:50
Originally posted by thana
i believe i'm able to do that ;)
(if i had known that this is such a hassle i wouldn't have bugged you about it in the first place, as its really only cosmetics).
I wouldn't have thought it'd be any problem either. Just insert \n here and there and be done with it. But unfortunately it wasn't :(
Mosu
20th June 2004, 18:53
I need some users willing to test my new bugs :)
I've changed a pretty central part of mkvmerge & mmg. From the ChangeLog:
* mkvmerge, mmg: new feature: --track-order now controls the track creation order globally, meaning that it isn't used for each file but only once. This allows the tracks to be created in ANY order (before it was first ordered by file, then by track). For mmg this means that the track list contains all available tracks and that there are no 'up' and 'down' buttons in the file list anymore.
Problem is that I'm pretty tired at the moment, so I've probably introduced a hell lot of bugs along the way. So if anyone wants to help me a bit please give this new build a try and report back: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-0.9.1-build20040620-6.rar
Thanks.
thana
20th June 2004, 20:35
Originally posted by Mosu
I need some users willing to test my new bugs :)
no problem. =)
in the track list only the first 7 entries gets checked by default after adding input files, the others are disabled (but can still be enabled). is this by design or is it a bug?
otherwise muxing in the strangest combinations with video, multiple audio and multiple different subtitle tracks (text+vobsubs) worked perfectly.
but the job management has some bugs now. when muxing many tracks or unusual combinations (like svq3+qdm2 from mov) by starting the job from the job management mmg crashes (although it muxes just fine when started from the main window). simple videos (like divx/xvid+mp3) work just fine. and another thing: when a job returns an error in the queue the log remains empty, so it becomes impossible to find out why a job failed after the queue finished.
by playing around with some files i noticed that mkvmerge doesn't recognise wma-audio v2 (also called DivX ;)-audio) in avi-files (displayed as 'unknown'). i know that its not defined on the matroska codecID-page and that m$ is evil and all, but msmpeg4 and wmv are supported too, so it seems logical to support the m$ audio codecs as well (and i think there are still many files around with this audio codec). also i have some files with adpcm-audio which isn't recognised too (ACM wFormatTag: 0x0002, according to vdubmod). wasn't the codecID A_MS/ACM intended for this?
Mosu
21st June 2004, 18:58
http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-0.9.1-build20040621-1.rar
Originally posted by thana
in the track list only the first 7 entries gets checked by default after adding input files, the others are disabled (but can still be enabled). is this by design or is it a bug?
A bug, of course. Fixed.
but the job management has some bugs now. when muxing many tracks or unusual combinations (like svq3+qdm2 from mov) by starting the job from the job management mmg crashes (although it muxes just fine when started from the main window). simple videos (like divx/xvid+mp3) work just fine.
Hmm, could you please upload such strange files + the job file belonging to that? You can find the corresponding job file in the 'jobs' subdirectory. It should have the name 'id.mmg' where 'id' is the job's id :)
and another thing: when a job returns an error in the queue the log remains empty, so it becomes impossible to find out why a job failed after the queue finished.
Ah thanks, fixed.
by playing around with some files i noticed that mkvmerge doesn't recognise wma-audio v2
...
wasn't the codecID A_MS/ACM intended for this?
Yes. Could you please upload such a file as well?
Thanks :)
thana
21st June 2004, 20:02
i uploaded 5 short clips and their job files under the subdirectory thana. the filenames are mostly self-explanatory, mmg crashes on the two movs and the mkv, the other 2 avis contain unsupported audio-codecs.
pixolex
23rd June 2004, 23:00
@mosu
well the problem with the always on top when the jobs are runing are half resolved...because i can't move all the windows...i have icons on the desktop and i can't reach them :( maybe the icon to minimize the active window (there are no icon in that window) should minimize all the non active windows.
Other thing...i understand that after hit the add job queue to start other job we have to select file->new , but it is possible to put a check box in the miscellaneous options to make the same efect that file->new does after hit the add botton?
...nothing to do with mktoolnix but i'm muxing 28 episodes in one big file (4,7 GB) with AVI-MUX GUI, making chapters automatically by file names. I don't know why but the program simply disapears when the process goes about 2,5 GB...maybe when mktoolnix suports that feature i can do that...:( i can't test it more because now i don't have many space left in the disk i need 8 GB free...
Mosu
25th June 2004, 10:21
Originally posted by pixolex
@mosu
well the problem with the always on top when the jobs are runing are half resolved...because i can't move all the windows...i have icons on the desktop and i can't reach them :( maybe the icon to minimize the active window (there are no icon in that window) should minimize all the non active windows.
I'll probably make that a button in the process dialogs.
Other thing...i understand that after hit the add job queue to start other job we have to select file->new , but it is possible to put a check box in the miscellaneous options to make the same efect that file->new does after hit the add botton?
Sure, I can add that.
...nothing to do with mktoolnix but i'm muxing 28 episodes in one big file (4,7 GB) with AVI-MUX GUI, making chapters automatically by file names. I don't know why but the program simply disapears when the process goes about 2,5 GB...maybe when mktoolnix suports that feature i can do that...:( i can't test it more because now i don't have many space left in the disk i need 8 GB free...
mkvmerge will support appending files - just not soon :(
Mosu
25th June 2004, 10:23
Originally posted by thana
i uploaded 5 short clips and their job files under the subdirectory thana. the filenames are mostly self-explanatory, mmg crashes on the two movs and the mkv, the other 2 avis contain unsupported audio-codecs.
Thanks. I haven't had time to look at them very thoroughly, though. So... One other question. What happens when you chose 'File -> open' and select one of those job files from the 'jobs' subdirectory and then start muxing? Does it not work like when it is started from the job manager?
thana
25th June 2004, 10:59
Originally posted by Mosu
What happens when you chose 'File -> open' and select one of those job files from the 'jobs' subdirectory and then start muxing? Does it not work like when it is started from the job manager?
in this case, mmg closes instantly after opening the .mmg file.
Mosu
25th June 2004, 15:03
Originally posted by pixolex
maybe the icon to minimize the active window...
Other thing...i understand that after hit the add job queue to start other job we have to select file->new , but it is possible to put a check box in the miscellaneous options...
http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-0.9.1-build20040625-1.rar
Mosu
25th June 2004, 15:03
Originally posted by thana
in this case, mmg closes instantly after opening the .mmg file.
Please try http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-0.9.1-build20040625-1.rar
(No, it doesn't support WMA yet)
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.