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
Mosu
1st September 2004, 13:45
Originally posted by Palikrovol
Hi.
When i add a new file to mmg (a speex audio file)...
Speex is not supported.
echo
1st September 2004, 21:50
Hey Mosu!
I don't quite understand what exactly the --append-to option does. Does it concatenate files as I suspect it does, or not? And what about the syntax?
mkvmerge --help shows:
--append-to <SFID1:STID1=DFID1:DTID1,SFID1:STID2=DFID2:DTID2,...>
A comma separated list of file and track IDs
that controls which track of a file is
appended to another track of another file.
But on the HTML help file in reads:
−−append−to <STID1:DTID1,[STID2:DTID2...]>
This option controls to which track a track of the current file is appended to. Each pair of track IDs maps the first ID from the following input file to the second ID from the previous input file. If this option has been omitted then a mapping of 0:0,1:1,2:2... is used.
From what I can tell about syntax the first one is the correct because I keep getting errors with the second. But I can't still figure out how to use it. Why won't the next command line work (if what this does is to concatenate files that is)?
mkvmerge -o test.mka --append-to 0:0=0:1,1:0=0:2 one.mp3 two.mp3 This results to exactly the same file as when the --append-to option is not used. Am I doing something wrong or am I just not getting it at all? Could you give an example of a command line with this option?
Thanks
echo
McGee
4th September 2004, 21:00
I'm having the same problem as Jcubed04 was having earlier. Every time I try to save the chapters to an .xml file, mmg.exe crashes. The previous version works fine.
Mosu
5th September 2004, 11:09
Originally posted by echo
Hey Mosu!
I don't quite understand what exactly the --append-to option does.
Nothing. I have added it in preparation for implementing concatenation / appending of several tracks and files. But that does not work yet, and it won't before the 1.0 release.
Mosu
5th September 2004, 11:11
Originally posted by McGee
I'm having the same problem as Jcubed04 was having earlier. Every time I try to save the chapters to an .xml file, mmg.exe crashes. The previous version works fine.
https://www.bunkus.org/anthill//query.php?bug=84
(i'm too lazy atm)
echo
5th September 2004, 13:07
Originally posted by Mosu
Nothing. I have added it in preparation for implementing concatenation / appending of several tracks and files. But that does not work yet, and it won't before the 1.0 release.
OK, thanks for the info. I've been waiting for this for a while. Glad to see that it will make it in 1.0. :)
Mosu
5th September 2004, 13:38
Originally posted by echo
OK, thanks for the info. I've been waiting for this for a while. Glad to see that it will make it in 1.0. :)
Sorry, wrong wording on my side. It won't be implemented in 1.0 but afterwards.
alexnoe
5th September 2004, 13:45
No, it was no wrong wording on your side. 'Not before 1.0' means 'not before 1.0'. You did not make any implication as to which version (having a number of at least 1.0) will have that feature.
ashyak
15th September 2004, 11:16
Hi,
my experience with 0.9.5:
simple muxing:
Video: Xvid 1.0.2
and
Audio: AAC HE VBR
MPC 6.4.8.2 with Matroska Pack 1.0.3 shows only 00:00 duration and it is not possible to seek in the movie, but the movie is playable :(
Is this a bug?
With mkvtoolnix 0.9.4 everything works fine.
....cu
Mosu
15th September 2004, 12:02
Originally posted by ashyak
MPC 6.4.8.2 with Matroska Pack 1.0.3 shows only 00:00 duration and it is not possible to seek in the movie, but the movie is playable :(
quote from my release notes:
A note to all Windows users: Files created with this new version require a new version of Gabest's Matroska splitter - at least 1.0.2.4 available from http://sourceforge.net/projects/guliverkli Alternatively you can use Haali's new splitter. Read about it on this thread on doom9.org: http://forum.doom9.org/showthread.php?s=&threadid=80762
Apart from that: with MPC you have to DISable its internal Matroska splitter.
hippoth
15th September 2004, 12:21
Hi Mosu
I didnīt read the release notes too and so I have tried now the new splitter. But this filter doesnīt work for me. I cant play Matroska with AC3 + subtiltes. A Matroska with AC3 or MP3 only works fine but the track names dont work there although I have given the tracks their names.
Is it a fault by the splitter or mkvtoolnix?
thana
15th September 2004, 12:24
a small bug i found in the latest prerelease version (2004-09-07):
when loading an mkv-file in the chaptereditor and minimizing the main window while parsing is in progress, and then restore the mmg-window after parsing is finished the parsing window isn't closed and you have to kill mmg.
btw, i saw in the changelog that you implemented a fast search for chapters/tags/etc. by using the seekhead info in mkvextract. it would be great if you could implement this in the chaptereditor too, parsing a big file would then be orders of magnitude faster i suppose. :)
Mosu
15th September 2004, 12:32
Originally posted by hippoth
Hi Mosu
I didnīt read the release notes too and so I have tried now the new splitter. But this filter doesnīt work for me. I cant play Matroska with AC3 + subtiltes. A Matroska with AC3 or MP3 only works fine but the track names dont work there although I have given the tracks their names.
Is it a fault by the splitter or mkvtoolnix?
The splitter's.
hippoth
15th September 2004, 12:36
Is it a known bug or should Gabest get informed?
Mosu
15th September 2004, 12:43
Originally posted by hippoth
Is it a known bug or should Gabest get informed?
I have no idea. But before you do that please get my latest mkvtoolnix build from http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/ and create that file with that version. If it still happens then file a bug report.
Mosu
17th September 2004, 14:37
Originally posted by thana
btw, i saw in the changelog that you implemented a fast search for chapters/tags/etc. by using the seekhead info in mkvextract. it would be great if you could implement this in the chaptereditor too, parsing a big file would then be orders of magnitude faster i suppose. :)
Hmm partially. I can do that when reading the file, but mmg needs to know where all level 1 elements are when writing the chapters to a Matroska file. So when mmg writes to a Matroska file for the first time it has to parse the file the way it is parsing it now upon reading it.
Mosu
17th September 2004, 14:54
Originally posted by thana
a small bug i found in the latest prerelease version (2004-09-07):
when loading an mkv-file in the chaptereditor and minimizing the main window while parsing is in progress, and then restore the mmg-window after parsing is finished the parsing window isn't closed and you have to kill mmg.
I can't reproduce this on Linux, so you'll have to wait a little longer until I've tried this on Windows, too.
Mosu
17th September 2004, 18:44
Originally posted by thana
a small bug i found in the latest prerelease version (2004-09-07):
when loading an mkv-file in the chaptereditor and minimizing the main window while parsing is in progress, and then restore the mmg-window after parsing is finished the parsing window isn't closed and you have to kill mmg.
Should be fixed in http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-0.9.5-build20040917-2.rar
Sirber
18th September 2004, 16:52
Can RealVideo G2 be muxed in Matroska?
Mosu
18th September 2004, 16:54
Originally posted by Sirber
Can RealVideo G2 be muxed in Matroska?
What is RealVideo G2?
Sirber
18th September 2004, 17:43
The video codec before RealVideo 8 :D
Mosu
18th September 2004, 17:45
Originally posted by Sirber
The video codec before RealVideo 8 :D
mkvmerge can handle all RV types: RV10, RV20, RV30, RV40. RV30 is... uhmmm... RealVideo 9 if I'm not mistaken. So the answer is probably 'yes'.
Why don't you just try it?
RadicalEd
18th September 2004, 19:11
RV40 = RV 9/10
RV30 = RV 8
RV20 = RV G2
RV10 = RV 1.0
#2
18th September 2004, 20:37
Hi Guys.
When I mux Rv9 with HE-AAC with 0.95 I get the seek bar in MPC 6.4.8.2 jumping to the end when the .mkv file is moved outside its original ripping dir. When played in its original ripping dir it seeks ok but has an echo with with the audio.
All works fine with 0.87
Mosu
18th September 2004, 20:38
Originally posted by #2
Hi Guys.
When I mux Rv9 with HE-AAC with 0.95 I get the seek bar in MPC 6.4.8.2 jumping to the end when the .mkv file is moved outside its original ripping dir. When played in its original ripping dir it seeks ok but has an echo with with the audio.
All works fine with 0.87
Get the latest pack from http://packs.matroska.org/ and DISable MPC's internal Matroska splitter and try again, please.
Sirber
18th September 2004, 20:41
@Mosu
Thanks!
#2
19th September 2004, 21:27
That fixed it.
Thanks Mosu.
Liisachan
26th September 2004, 11:17
Is there any way to change "Default duration" for an audio track--for instance 24.000ms for A_MPEG/L3--when muxing with mkvmerge?
I'm asking this because the following commands do not work as accurate as I wish:
mkvmerge -o work.mka vsshort.mp3 --split 00:00:24.000
mkvextract tracks work-001.mka 1:24sec000.mp3
mkvmerge -o work.mka vsshort.mp3 --split 00:00:24.010
mkvextract tracks work-001.mka 1:24sec010.mp3
mkvmerge -o work.mka vsshort.mp3 --split 00:00:24.020
mkvextract tracks work-001.mka 1:24sec020.mp3
mkvmerge -o work.mka vsshort.mp3 --split 00:00:24.030
mkvextract tracks work-001.mka 1:24sec030.mp3
mkvmerge -o work.mka vsshort.mp3 --split 00:00:24.040
mkvextract tracks work-001.mka 1:24sec040.mp3
mkvmerge -o work.mka vsshort.mp3 --split 00:00:24.050
mkvextract tracks work-001.mka 1:24sec050.mp3
The actual duration you'll get will only have a resolution of 24 milliseconds, like:
24sec000.mp3 -> 23.976
24sec010.mp3 -> 24.000
24sec020.mp3 -> 24.000
24sec030.mp3 -> 24.024
24sec040.mp3 -> 24.024
24sec050.mp3 -> 24.048
I know that MKVtoolnix is not a tool for audio editing, but sometimes you might need to split a big audio file very accurately, like with a resolution of 1 ms... :)
Mosu
26th September 2004, 11:39
Originally posted by Liisachan
Is there any way to change "Default duration" for an audio track--for instance 24.000ms for A_MPEG/L3--when muxing with mkvmerge?
No, sorry. The default duration highly depends on the codec in use. E.g. MP3 (meaning exactly MPEG1 layer 3) always has 1152 samples per frame, so the default duration is always 1152/sample_rate for MP3.
Also mkvmerge can only split on packet boundaries. So for MP3 the smallest resolution for splitting is 1152 samples.
Liisachan
28th September 2004, 11:58
I see. thanks for clarifying.
Atamido
28th September 2004, 16:45
Note that this would be the same for all editing tools. If you needed to cut in the middle of an MP3 frame, it means you are going to need to reencode that frame.
stephanV
28th September 2004, 16:55
i think it would actually mean re-encoding the whole audiostream... not just one frame...
Atamido
28th September 2004, 17:16
Well, depending on the audio format, and the particulars of the frame being dealt with, you could theoretically get away with just reencoding just a frame or a couple of frames. But as there is no tool that I know of to do that, I would guess that you would indeed need to reencode the entire audio stream.
Liisachan
28th September 2004, 17:19
Originally posted by Pamel
Note that this would be the same for all editing tools. If you needed to cut in the middle of an MP3 frame, it means you are going to need to reencode that frame. excuse me but what do you mean by "middle of an MP3 frame"? :confused: I guess it's given that a frame (that is like 0.02 ms) is an atom. I guess what you meant was "to cut at the point that is not a packet boundary" (that occurs each 24 ms)... and I didn't know that. When Mosu said "frame-accurate" I fancied that I would be able to edit audio very accurately using MKA ^^;
stephanV
28th September 2004, 17:31
Its just a restriction of the MP3 format, not of MKA or any other kind of container. Each MP3 frame has a fixed length (1152 samples) and it is not possible to decode only part of a frame. Although you can happily cut MP3-frames in half (the way VDub stores MP3 in AVI will very likely result in this), the decoder would output nothing but garbage for that frame if you do so.
Not being able to cut at "the middle of a MP3 frame" is just other words for not being able to cut on "a point that is not a packet(=frame) boundry".
Liisachan
28th September 2004, 18:04
Ah! Now that makes sense, thanks so much! I was confused about "sample != frame" Thank you for your patience for my ignorance. I'm now a bit wiser :D
Liisachan
30th September 2004, 14:12
These are not bugs, nor MKVToolnix's fault. But let me report 2 things I'm feeling here, fyi...
(1) Track ID for Ogg Vorbis is confusing:
Imagine this scenario: Let's say here's a windows user who has vsshort.avi (vid only) and vsshort.wav, and he would decide to use Ogg Vorbis and would do
oggenc -q 3 vsshort.wav
to get vsshort.ogg, and then he'd open mmg.exe to mux an MKV file.
mmg would generate a long command line which would look like
"H:\local\bin\mkvmerge.exe" -o "G:\test\vsshort.mkv"
--command-line-charset UTF-8 -d 0 -A -S G:\test\vsshort.avi
-a 4937 -D -S G:\test\vsshort.ogg --track-order 0:0,1:4937
It's all good and fine. But the problem occurs when he happens to re-encode Vorbis, like "Oh, maybe -q 3 is not good enough, I'll change the q' and he would do
oggenc -q 5 vsshort.wav
If he doesn't know well about the Track ID of .ogg file, he might think to himself "Since I'll mux vsshort.avi and vsshort.ogg again--each of the input files and the output file has the same name, so I can just hit [Start muxing] in mmg." But that wouldnt work, because the Track ID of the .ogg file will change if you reencode it.
Probably we should accept this, but I find it a bit too confusing that mmg.exe says "Everything went fine" even when the Track ID of .ogg is wrong (because re-encoded) and the resulted MKV file doesnot have the audio track. I guess it's not the situation where one can say Everything went fine. I'm not a dev so what I'm fancying might be too dreamy, but it might be nice if you can specify (for example) -1 like this:
--language -1:eng -a -1 -D -S vsshort.ogg
Where -1 would be the meta value for the return-value of "mkvmerge --identify vsshort.ogg"
when I'm using mmg, I often feel that Vorbis's Track ID is confusing--.ogg file has only one audio track but the track ID is unpredictable... WHY cant it just be called Track #1? (On the other hand, I guess that might be reasonable because in the future .ogg file might have more than one tracks, like Theora and Vorbis)
(2) "Cut off audio when video stream ends" Option would be useful:
Let's say I'm muxing a 30sec video and 40-sec audio to make an MKV file. Then mkvmerge would generate a 40-sec MKV file, with vid only for 30 secs and then audio-only for the last 10 secs. This feature is logical and really convenient in some situations (where the last 10 sec of the audio is important), but inconvenient in other situations. Like VirtualDubMod's default, I'd like to have "Cut off audio when video stream ends" Option. Especially, audio from DVD is sometimes longer by 0.5 sec or so than the corresponding video (trailing 0.5 sec of the audio is meaingless silence)...if for some reasons you mux several chapters separately, getting chap1.mkv chap2.mkv...and then if you concatenate those MKVs, probably the result will be out of synch because of the 'padding audio without vid' at the end of each files...
Liisachan
1st October 2004, 13:15
Yet another report:
To make mmg foolproof, Please tell "mkgmerge executable" (HKEY_USERS\...\Software\mkvmergeGUI\GUI) not to accept "mmg.exe" itself. Today I was testing different versions of mkvmerge's from mmg, hit [Browse] to select mkvmerge.exe to use, but I accidentally specified the path to mmg.exe itself there and mmg.exe accepted it. Then I got a real mess when I tried to run mmg.exe again. mmg.exe thought it should call mmg.exe which thought it should call mmg.exe which thought...and I got like 30 instances of mmg.exe.
silly me, it messed up the OS itself too, and I had to use regedit (usually, you can change the settings of mmg from mmg, but in this case you'd have to run mmg.exe to do so, but you couldnt because of the infinite loop)
Mosu
1st October 2004, 13:26
Originally posted by Liisachan
Yet another report:
To make mmg foolproof, Please tell "mkgmerge executable" (HKEY_USERS\...\Software\mkvmergeGUI\GUI) not to accept "mmg.exe" itself. Today I was testing different versions of mkvmerge's from mmg, hit [Browse] to select mkvmerge.exe to use, but I accidentally specified the path to mmg.exe itself there and mmg.exe accepted it. Then I got a real mess when I tried to run mmg.exe again. mmg.exe thought it should call mmg.exe which thought it should call mmg.exe which thought...and I got like 30 instances of mmg.exe.
Yuck :) Funny :) I'll change that.
Mosu
1st October 2004, 13:41
Originally posted by Liisachan
These are not bugs, nor MKVToolnix's fault. But let me report 2 things I'm feeling here, fyi...
(1) Track ID for Ogg Vorbis is confusing:
Hmm... The IDs used for Ogg files are the stream IDs oggenc choses, and oggenc uses random IDs for those. I guess I could change that so that mkvmerge's track IDs refer to the "stream number" (e.g. '--language 2:eng' using the third stream found in the file) and not to the stream IDs anymore.
https://www.bunkus.org/anthill/query.php?bug=97
Probably we should accept this, but I find it a bit too confusing that mmg.exe says "Everything went fine" even when the Track ID of .ogg is wrong (because re-encoded) and the resulted MKV file doesnot have the audio track.
Ok, mkvmerge needs some more checks for this -- e.g. "Warning: there is no track with the ID 12345 in file xyz.ogg" and "Warning: No tracks will be copied from file zyx.ogg". A lot of work, though, but I'll put it on my TODO list (= into my bug tracking system):
https://www.bunkus.org/anthill/query.php?bug=98
I guess it's not the situation where one can say Everything went fine. I'm not a dev so what I'm fancying might be too dreamy, but it might be nice if you can specify (for example) -1 like this:
--language -1:eng -a -1 -D -S vsshort.ogg
Where -1 would be the meta value for the return-value of "mkvmerge --identify vsshort.ogg"
"Copy all tracks of a kind" e.g. "copy all audio tracks" is done with leaving out the "-a" parameter completely. However, mmg wants and needs full control, so it always lists all tracks that are to be copied. If I change the track ID meaning like I've said above you won't need this to change, tough, so I'll just leave it as it is.
when I'm using mmg, I often feel that Vorbis's Track ID is confusing--.ogg file has only one audio track but the track ID is unpredictable... WHY cant it just be called Track #1?
Because oggenc choses random stream IDs and mkvmerge uses those for its track IDs, too. Until now that is :)
(2) "Cut off audio when video stream ends" Option would be useful:
While I do agree that this might be useful it won't happen. The problem is recognizing when the video track has ended and not just a gap in the middle. With some file formats (AVI, Quicktime, RM, Ogg IF it is implemented correctly) you can tell that a stream has ended, but not with Matroska. So finding the end of the video stream would involve either very, very intricate buffering OR a complete scan of those files for which the end cannot be determined.
VDubMod choses the latter approach and scans each file when opening it, but I'm against doing that. mkvmerge is already slow enough as it is (it's not multi threaded and suffers from many small read/write operations from/to the files), and that would add a considerable amount of time to the muxing process.
So for now I'll say "no sorry". Maybe I'll add such an option in the future.
Liisachan
1st October 2004, 23:05
Originally posted by Mosu
I guess I could change that so that mkvmerge's track IDs refer to the "stream number" (e.g. '--language 2:eng' using the third stream found in the file) and not to the stream IDs anymore. That'd be great if it's not too much trouble to do so. But I don't think it a bug. Just a little bit confusing.
Ok, mkvmerge needs some more checks for this -- e.g. "Warning: there is no track with the ID 12345 in file xyz.ogg" and "Warning: No tracks will be copied from file zyx.ogg". A lot of work, though, but I'll put it on my TODO list (= into my bug tracking system): Yes, I suppose THAT is very preferable for stable "1.0 release".
As for "Cut off audio when video stream ends" Option, I understand the problem now and it's acceptable. You could just use your audio editor anyway if millisecond accuracy means that much :)
Yet Another Bug Report :D
TTA format supports ID3v1/v2 tags. (http://tta.iszf.irk.ru/?menu=format) However, mkvmerge fails to parse TTA if it is tagged.
demo (890KB) (http://www.faireal.net/tmp/tagged_tta.zip) with 2 TTA files, "no tags.tta" and "tagged.tta"--the 2 files are identical except one thing--"tagged.tta" has a tag TITLE=foo. ttaenc -t says both files are valid, but mkvmerge can only accept the 1st file (without tags).
G:\test\Tagged TTA Test>ttaenc -t "no tags.tta"
TTA1 lossless audio encoder/decoder, release 3.1
Copyright (c) 2004 Alexander Djourik. All rights reserved.
For more information see http://tta.corecodec.org
------------------------------------------------------------
File: [no tags.tta]
------------------------------------------------------------
Total: [1/1] succeeded, time: 0'00
------------------------------------------------------------
G:\test\Tagged TTA Test>ttaenc -t "tagged.tta"
TTA1 lossless audio encoder/decoder, release 3.1
Copyright (c) 2004 Alexander Djourik. All rights reserved.
For more information see http://tta.corecodec.org
------------------------------------------------------------
File: [tagged.tta]
------------------------------------------------------------
Total: [1/1] succeeded, time: 0'00
------------------------------------------------------------
G:\test\Tagged TTA Test>mkvmerge -o 1.mka "no tags.tta"
mkvmerge v0.9.5 ('The Na Na Song') built on Aug 17 2004 16:10:00
'no tags.tta': Using the TTA demultiplexer.
'no tags.tta' track 0: Using the TTA output module.
The file '1.mka' has been opened for writing.
progress: 459299/459299 bytes (100%)
The cue entries (the index) are being written...
Muxing took 0 seconds.
G:\test\Tagged TTA Test>mkvmerge -o 2.mka "with tag.tta"
mkvmerge v0.9.5 ('The Na Na Song') built on Aug 17 2004 16:10:00
Error: The source file 'with tag.tta' could not be opened successfully,
or retrieving its size by seeking to the end did not work.
G:\test\Tagged TTA Test>
Mosu
2nd October 2004, 10:01
Originally posted by Liisachan
Yet Another Bug Report :D
TTA format supports ID3v1/v2 tags. (http://tta.iszf.irk.ru/?menu=format) However, mkvmerge fails to parse TTA if it is tagged.
Your file contains APE tags which mkvmerge does not support.
G:\test\Tagged TTA Test>mkvmerge -o 2.mka "with tag.tta"
mkvmerge v0.9.5 ('The Na Na Song') built on Aug 17 2004 16:10:00
Error: The source file 'with tag.tta' could not be opened successfully,
or retrieving its size by seeking to the end did not work.
Interesting - I get another error message:
Error: 'tagged.tta': The seek table in this TTA file seems to be broken.
Anyway, like I said: APE tags are not supported. ID3v1/v2 tags should be skipped correctly in 0.9.5.
niamh
3rd October 2004, 05:47
Mosu, I can't seem to mux properly a file with 2 HE-AAC tracks, 1 mp3(CBR 48K) track and 2 srt. Apologies if this has been fixed since 9.5 official which is the one I have. The issue is I have no sound on the mp3 track(works fine on its own,worked fine with 2 AAC and 1 OGG), and the video skips too;so I tried with 9.3, still no sound.
I then tried to cut a bit to send you, but 9.5 returns an error code 2, after the cues are being written : couldn't open the file for writing, and 9.3 simply crashed (encountered error bla bla)
I'm sending the full file and will cut it off at some stage. It's Monty python and the holy grail :)
Liisachan
3rd October 2004, 07:05
Originally posted by Mosu
APE tags are not supported. ID3v1/v2 tags should be skipped correctly in 0.9.5. Sorry for confusing APE tags and IE3v1/v2 tags. So, TTA can have APE tags, but MKVMerge cannot accept TTA with APE tags, and it is a spec... Ok, I'll remember that. Thank you for clarification.
Mosu
3rd October 2004, 08:03
Originally posted by niamh
I'm sending the full file and will cut it off at some stage. It's Monty python and the holy grail :)
Could you please upload the MP3 file, too? Thanks.
Mosu
3rd October 2004, 08:08
Originally posted by Liisachan
Sorry for confusing APE tags and IE3v1/v2 tags. So, TTA can have APE tags, but MKVMerge cannot accept TTA with APE tags, and it is a spec... Ok, I'll remember that. Thank you for clarification.
TTA's homepage only mentions ID3v1/v2 tags. In fact you can attach ID3v1/v2 tags to each and every file -- the format doesn't have to be prepared for that. You could even attach those tags to Matroska files. But the applications dealing with such files would not expect them and not support them.
I guess it's the same with APE tags. You can append them to every file format, but you should not expect the applications to handle them.
niamh
3rd October 2004, 09:13
sending now :)
Mosu
3rd October 2004, 09:42
Originally posted by niamh
sending now :)
Interesting file. mkvmerge is doing its job correctly, but there are decoders that seem to fail on it. I've tried mplayer with libMAD ("mplayer -afm libmad ...", fails), ffmpeg ("-afm ffmpeg", works) and mp3lib ("-afm mp3lib", works).
So it's a playback issue.
niamh
3rd October 2004, 10:16
So that explains why it won't load back in mkvmerge for splitting? It's indeed curious as it's a simple besweet CBR file I made last night. Ah well :o (bitrate too low maybe?) thx :)
Mosu
3rd October 2004, 10:21
Originally posted by niamh
So that explains why it won't load back in mkvmerge for splitting?
I can remux the file you've uploaded just fine, and mmg accepts it, too. Can you please download the latest build from http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-0.9.5-build20040928-1.rar and see if this one can handle your MKV?
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.