Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
13th July 2009, 21:28 | #1101 | Link | |||
MKVToolNix author
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
|
Quote:
Quote:
Quote:
__________________
Latest MKVToolNix is v83.0 If I ever ask you to upload something, please use my file server. |
|||
15th July 2009, 02:11 | #1102 | Link |
Registered User
Join Date: Mar 2009
Posts: 14
|
Two possible bugs:
For subtitle tracks, the Default track flag, if set to "default", is being set to Yes instead, as seen when I open the muxed file in MMG. If I set the flag to No, mux, open the file, its now set to Default. For chapter tracks, the language value is not being saved to the muxed file. |
15th July 2009, 08:17 | #1103 | Link | ||
MKVToolNix author
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
|
Quote:
Setting the drop down box to "No" results in the DefaultTrack flag being set to "0" for that track for me, so I cannot reproduce this. Anyway, I doubt that there's really a bug. Quote:
__________________
Latest MKVToolNix is v83.0 If I ever ask you to upload something, please use my file server. |
||
16th July 2009, 04:22 | #1104 | Link | ||
Registered User
Join Date: Mar 2009
Posts: 14
|
Quote:
Could you provide a global setting that would by default copy all track attributes as they are? This would help a lot, especially when re-muxing. When I load a file that contains subs, I'd rather it show "No" if that is what the sub track was originally set to. Quote:
Last edited by fingershop; 16th July 2009 at 04:25. |
||
16th July 2009, 08:00 | #1106 | Link | ||
MKVToolNix author
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
|
Quote:
Quote:
__________________
Latest MKVToolNix is v83.0 If I ever ask you to upload something, please use my file server. |
||
16th July 2009, 20:07 | #1107 | Link | |
MKVToolNix author
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
|
Quote:
http://www.bunkus.org/videotools/mkv...-158-setup.exe
__________________
Latest MKVToolNix is v83.0 If I ever ask you to upload something, please use my file server. |
|
16th July 2009, 21:47 | #1108 | Link | |
Registered User
Join Date: Mar 2009
Posts: 14
|
Quote:
|
|
16th July 2009, 22:40 | #1110 | Link | |
Registered User
Join Date: Mar 2009
Posts: 14
|
Quote:
I understand. And since we're on the subject... here are two related wishes of mine for your consideration: 1) The ability to add chapter text files to the track list in the same way as other track types. Most chapters I work with are unique to each muxed file and are not global, and I'm constantly forgetting to remove or update the chapters file on the global tab. 2) For chapters in the track list, I'd like to open them in the Chapter Editor to edit them, and then use this edited version when I mux (maybe a "save track changes" command on the Chapter Editor menu?). An alternate version of this wish would be: to allow setting a Delay for chapter tracks, the same as other track types. A large part of my reason for these requests is that I'm converting my dvd collections to mkv, and I like keeping the original chapters from the dvds. The ripper I use saves the chapters in a file with the same name as the individual vobs and/or individual streams, and I can quickly add these files to mmg by using a wildcard file extension in the Add window -- except for the chapter files that are currently entered separately on the Global tab. After the initial mux, I need to briefly play each file and test the chapters to make sure they line up correctly, and if they don't then I need to adjust their timing. This would be much quicker and easier if adjusting (or editing) chapter timings were possible from the track list. |
|
17th July 2009, 07:52 | #1111 | Link | ||
MKVToolNix author
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
|
Quote:
Quote:
The time I save you is very short compared to the time it would require me to implement such features. And free time is the one thing that I do not have in abundance. I'm not against implementing those features per se. If someone contributed a patch that implemented them I'd happily accept it. That someone just won't be me.
__________________
Latest MKVToolNix is v83.0 If I ever ask you to upload something, please use my file server. |
||
17th July 2009, 07:54 | #1112 | Link |
MKVToolNix author
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
|
In case anyone wonders. What I am working on is fixing bugs (always time consuming) and dealing with support requests (even more time consuming). The next two new big features will be support for MPEG transport streams (will take huge amounts of time to do it right -- especially with all those abominations of spec violations out there) and support for specifying cut points ("only copy from timecodes A to B and from K to L", again a lot of work) -- probably in that order.
__________________
Latest MKVToolNix is v83.0 If I ever ask you to upload something, please use my file server. |
17th July 2009, 18:22 | #1113 | Link |
Registered User
Join Date: Jun 2005
Posts: 630
|
Good luck with that, that would be a very cool feature. I completely agree regarding all the possible abominations. I don't know any .ts related software which would be able to process properly all the kinds of different .ts files I have. Amongst them, DGIndex is probably most stable, though not for all files. Proper implementation may indeed take a great deal of time...
|
17th July 2009, 23:14 | #1114 | Link | |
Registered User
Join Date: Feb 2005
Posts: 585
|
Quote:
__________________
Chumbo |
|
18th July 2009, 23:37 | #1115 | Link | ||
Registered User
Join Date: Mar 2009
Posts: 14
|
Quote:
Quote:
Cheers! |
||
18th July 2009, 23:46 | #1116 | Link |
MKVToolNix author
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
|
In fact I haven't really started working on TS support yet (apart from two, three hours of reading ffmpeg's/mplayer's source code). But what little free time I do have I don't want to spend on other features.
__________________
Latest MKVToolNix is v83.0 If I ever ask you to upload something, please use my file server. |
21st July 2009, 08:26 | #1117 | Link | |
Registered User
Join Date: Aug 2007
Posts: 1,430
|
Croatian (scr) seems to be missing from valid language choices in the newest builds. Every time I try to mux an mkv I made with scr set as one of the languages (done with v2.4.1), 2.9.7 says
Quote:
Edit: And that solves that.. http://www.bunkus.org/cgi-bin/gitweb...df55390505aa71 Last edited by Snowknight26; 21st July 2009 at 08:35. |
|
21st July 2009, 09:12 | #1118 | Link |
MKVToolNix author
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
|
Correct. 'scr' was an obsolete code that has been removed because it has been removed from the official ISO639-2 lists as well.
__________________
Latest MKVToolNix is v83.0 If I ever ask you to upload something, please use my file server. |
21st July 2009, 14:29 | #1119 | Link |
Registered User
Join Date: Dec 2008
Location: Germany
Posts: 173
|
Feature Request
I often read (and had) some mkv have errors in EBML-Structure.
Now I´m asking if it is possible to repair such errors. There is no known methode or program for repairing such errors, but fact is: - These files often play (with errors on scrubbing or jumping on timeline) with some players. - You can not demux/extract them or do any other things with them until to this specific error-position. Is it possible to repair those files ? Recovering Data is of course maybe impossible, but maybe its possible to scan the whole stream an rewrite/reorder/skip some Header, or skip faulty Bytes who are damaged. I mean: Its better to get a repaired file with "one frame missing" (due wrong EMBL-Entry) as loosing the whole file. Or maybe: Implementing a check after muxing. These EBML-Errors must have its fault somewhere. Maybe a check after muxing should be fine. Regards |
22nd July 2009, 08:29 | #1120 | Link |
MKVToolNix author
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
|
My answer will be a bit longer. Get some coffee.
You're talking about two different aspects: error prevention and error recovery. Error prevention: I can almost guarantee that the muxing process produces 100% correct EBML structures. The libraries I use have been basically unchanged for five years, and there's not a single confirmed report that one of my tools create corrupt EBML structures. Also having a check after muxing imposes a false sense of security due to several reasons: 1. The library used for validation would be the same library used for creation. If one is serious about validation then this is a no go. 2. Caching. The file just created will always be partially cached by the operating system, and how big this part is depends on various factors like overall memory size, operating system type and version and current memory usage. Therefore the validation process would not be able to test if the file is stored correctly on the hardware ( = hard disc, flash drive etc) reliably. Which leads me to the two obvious reasons and another not so obvious one why files get corrupted. The first is bad hardware. This is actually more common than one might think or hope. Having unrecoverable hard disc read errors does occur, it's no myth. While this is usually not a fatal error in the sense that the hard disc cannot be used anymore (due to techniques like sector reallocation) it does mean that data read from that sector is corrupt and that the application has to deal with it. This is even more common for flash drives. Most flash drives use cheap memory, and those chips (cheap or not) are very susceptible to things like environmental conditions etc. Those things are not suited for long-term data storage. I even go so far as to create checksums of all important files that I transfer with flash drives due to past experience with corrupted files. The second cause is bad transmission. Downloading files from the Internet (no matter if it's legal or not) always poses a risk of data transmission errors. If checksum files are available together with the download then you should always use them to verify data integrity. The not so obvious reason applies to illegal downloads. There are companies working for the major movie and music studios that create faulty files or files that are 100% garbage, name them after certain popular movies and offer them for download. Like I already said: use checksum tools for error detection even if you store your files locally. They're freely available and only require a little bit more work. Now on to error recovery. The library mkvmerge uses is not good in dealing with faulty files. Sometimes it can recover and continue from the next valid cluster, but often it cannot. There's nothing I can do about it, or at least nothing I'm willing to do due to the huge amount of time involved in creating my own set of libraries and changing about 60% of all of mkvmerge's code that depends on this library either directly or indirectly. If you need error recovery and restoration of original files then there are external techniques like PAR files that can offer increased security at the cost of a certain percentage of the file's size.
__________________
Latest MKVToolNix is v83.0 If I ever ask you to upload something, please use my file server. |
Thread Tools | Search this Thread |
Display Modes | |
|
|