View Full Version : MuxMan (free ed.) and chapters
Ghitulescu
23rd November 2012, 16:58
It happened several times but since the distance between the events (I am not using it too often) was very large I did consider at that times that it was a user error.
After muxing a video with several audio tracks and several subtitle tracks, the DVD structure is created, but the chapter list contains only the first one. So the VOBs contain the whole movie, just that the PGC containing the movie (the only one :)) contains only one cell, the first one VID 1/1.
So far I couldn't find any tool to let me add back the "lost" chapters.
The solutions I had were 2:
- remux again the whole thing (takes time and space, both commodities I don't have)
- use IfoEdit's create IFOs function, which deletes all the information I previously had
In case it's important the version is 168.
Anyone has a solution or an explanation?
manolito
23rd November 2012, 17:14
While I do not have an explanation why Muxman does this to you (no error message in the Muxman log file?), I do know an older tool which can edit chapters without remuxing.
It is called "Capter Edit", here's the readme:
*** Chapter Edit 1.10 (English Version) ***
"Chapter Edit" can edit chapter positions on the DVD video image.
Multi title is not supported.
Original DVD menus are deleted.
"Chapter Edit" is free ware.
User support service is not provided generally.
Please avoid contact with author(requests, questions etc).
<Usage(Overview)>
1. Specify [Input Folder].
2. Push [Read VOB files] button.
3. Set chapters on the time list by using following buttons and menus.
[Chapter on/off] button
[Clear chapters] button
[Chapter->Interval] menu
[Chapter->Chapter list [New]] menu
[Chapter->Chapter list [Append]] menu
4. Specify [Output Folder].
5. Push [Create DVD Image] button.
=======================================================================
<Other operations>
[up/dw] button : Jump cursor to the pre/next cell boundary.
[UP/DW] button : Jump cursor to the pre/next chapter boundary.
[Play] button : Play movie from the cursor position.
[Play A-B] button : Play movie on the marked range.
[Play continue] button : Play movie from the last played position.
[Setting] button : Set DVD(VOB) soft player and preview setting.
[Help] button : Display help.
[Exit] button : End program.
=======================================================================
<CHPLIST.TXT file format(HH:MM:SS)>
e.g.
00:00:00
00:02:30
00:14:30
00:26:30
00:27:45
00:30:00
:
:
Since your DVD only has one title, this tool might work for you. PM me if you can't find it...
Good luck
manolito
//Edit//
Just found a download link:
http://forum.digital-digest.com/attachments/f14/3243d1131595882-chapter-edit-1-10-english-version-chapter-edit-v1.10.zip
r0lZ
24th November 2012, 11:52
Maybe a stupid question, but are you sure you have imported the celltime.txt file before launching the mux, and that it is in the correct format? muxman should show the number of scenes in the bottom part of its window.
Groucho2004
24th November 2012, 11:58
Maybe a stupid question, but are you sure you have imported the celltime.txt file before launching the mux, and that it is in the correct format? muxman should show the number of scenes in the bottom part of its window.
I was wondering about this as well. I always import the chapters in text format and this always works perfectly in Muxman.
Ghitulescu
28th November 2012, 16:21
I did today another mux. This time I put the chapters by hand (all 24 of them). And guess what? Still one cell with 5 minutes duration (incidentally the duration I set by hand).
Sir Didymus
29th November 2012, 09:59
...no error message in the Muxman log file?...
What manolito suggests is fundamental... Muxman creates a log file under the root of your principal partition (usually "C:"). Could you check/post what this file is reporting?
Cheers,
SD
Ghitulescu
29th November 2012, 10:51
I don't have writing rights in the root so I don't have any log.
Otherwise I would have found myself the cause.
Groucho2004
29th November 2012, 11:21
Muxman creates a log file under the root of your principal partition (usually "C:").
The version I use (which is the latest) creates the log file in the same directory from where it is started.
I do however vaguely recall that previous versions of Muxman used to write to the root of c:, not sure.
r0lZ
29th November 2012, 11:28
Muxman creates a log file under the root of your principal partition (usually "C:").
It's a bad idea, as it's prohibited. It should write the log somewhere in the user's home (in %APPDATA% for example).
Under Windows 7 (and probably 8), it cannot write to the root of the system drive any more, but what a program tries to write there is automatically redirected by Windows to the "VirtualStore". You should find the muxman log there. Usually, the VirtualStore folder is "C:\Users\<you>\AppData\Local\VirtualStore".
Sir Didymus
29th November 2012, 16:31
<<
I don't have writing rights in the root so I don't have any log.
Otherwise I would have found myself the cause.
>>
<<
It's a bad idea, as it's prohibited. It should write the log somewhere in the user's home...
>>
Right, right... I was speaking about the default behaviour (of a version which is possibly not the latest one, as Groucho2004 points out)... However the log file, which is fundamental to understand if the authoring session is properly carried out, can be easily created wherever you have write permissions, by launching Muxman via C/L, with the option "-l"... OK?
Cheers,
SD
Groucho2004
29th November 2012, 16:44
The log file, which is fundamental to understand if the authoring session is properly carried out, can be easily created wherever you have write permissions, by launching Muxman via C/L, with the option "-l"...
...or changing the "LogFile" entry in "muxman.ini" located in "%WINDIR%".
Richard1485
17th January 2016, 10:38
I am experiencing this problem yet again. I discussed it here (http://forum.doom9.org/showthread.php?t=171070). Ghitulescu, did you ever find a solution?
EDIT: I most certainly am importing my chapters from Celltimes.txt generated by PGCDemux.
EDIT: I strongly suspect that the following is the problem.
Normally, when I select the VIDEO_TS.IFO of a DVD in a software player, it plays the whole movie; however, when I do this with the output from MuxMan, it plays only up to the end of the first chapter.
Is there a way to instruct MuxMan that one is producing a movie-only DVD?
EDIT: From the log...
Reference to non-existant scene "Segment_1_scn51" from PGC "VTS01_TTL01_PGC1"
This message shows up sometimes when muxing this content but not always. I don't understand it. That scene is not out of bounds. I have checked it – both pre-pulldown and post-pulldown.
EDIT: MuxMan muxes successfully if I delete the final chapter, which is 51. (See above.) This helps, but it's frustrating because I want that last chapter, and I cannot see how it is out of bounds.
Sir Didymus
17th January 2016, 15:08
The MuxMan message say very clearly and obviously that the authoring engine is trying to reference a scene (defined by your chapter file) which is not-existant.
For plenty of very valid reasons, it may easily happen that the cellframes.txt file, created automatically by thyrdy party demuxers or ifo editors, IS NOT consistent with the chapter point you would expect to insert into your compilation.
For instance it may happen because of structural protection: zero frames or 1 frame cells included in the PGC, for the addition of a very final 1 frame blank video frame at the end of the PGC added sometimes in the authoring sessions to simplifying some navigation issues, etc... There are as I say also other frequent use cases.
If you try to use one asset (the chapter definition file), without checking in advance that it consistently suits with the other assets (the video), than the fault is on you side, not in the authoring program... :-)
"Consistently suits" means cheching that each individual chapter point correspond to a given I-frame in the movie, where the scene-change is wanted...
OK?
To make shorter (and nicer, maybe) my reply: please just check the chapter.txt file contains valid information, before launching MuxMan...
All the best,
SD
Edit (after your last editing)... One last chapter out of bounds, frequently happen because the authoring software is simply unable to include this last chapter point, because there are not enough video frames in the movie (one GOP duration should be as the minimum around about 0.5 sec.). A good solution in these cases is to add some blank frames at the end of the video asset to make it compliant, or to remove the last chapter if it is not really useful...
Richard1485
17th January 2016, 15:21
If you try to use one asset (the chapter definition file), without checking in advance that it consistently suits with the other assets (the video), than the fault is on you side, not in the authoring program... :-)
I agree. This is why I have checked that the chapter file refers to a frame that is not out of bounds. It's also why I instructed my encoder (HCenc) to position I-frames in suitable places.
I obtained the chapters from PGCDemux and have not altered them. These frames are non-drop frames, as was established in the thread to which I linked above. When instructing HCenc to position I-frames, I had to convert them to pre-pulldown frame-numbers because if you feed HCenc 23.976fps material, even with the pulldown radio button checked, it requires pre-pulldown frame-numbers. Perhaps something is going wrong with my conversion from post-pulldown to pre-pulldown frame-numbers, but I don't know what it is. I multiply them by 0.8.
Edit (after your last editing)... One last chapter out of bounds, frequently happen because the authoring software is simply unable to include this last chapter point, because there are not enough video frames in the movie (one GOP duration should be as the minimum around about 0.5 sec.). A good solution in these cases is to add some blank frames at the end of the video asset to make it compliant, or to remove the last chapter if it is not really useful...
I see, but my script matches the original video that produced the Celltimes.txt down to the last frame. I am very thorough with things like that. And the last chapter is indeed useful.
r0lZ
17th January 2016, 15:34
If you really need it, you can easily add a blank dummy chapter (with just a single frame) at the end of the PGC with PgcEdit. Use the "Create new cell" button in the PGC Editor.
Richard1485
17th January 2016, 15:38
Thanks, r0LZ. I really appreciate the suggestion, but I am fairly sure that there is something elementary that I am overlooking and can fix. I do this sort of work quite frequently and want to avoid having to introduce another step to my workflow if at at all possible. :-)
EDIT: I wish that were a frame-number converter of some kind. ChapterGrabber will convert time-codes but not frame-numbers.
manolito
18th January 2016, 03:09
EDIT: I wish that were a frame-number converter of some kind. ChapterGrabber will convert time-codes but not frame-numbers.
Hi Richard and Sir Didymus,
ChapterGen by shon3i can import a celltimes.txt file with frame numbers (IfoEdit format). You can even specify input- and output frame rates to convert the frame numbers for pulldown.
It is kind of funny how old and long forgotten things reappear at a later time...
Many years ago Sir Didymus wrote an authoring plugin for DVD2SVCD where I was a little bit involved (still using it frequently, thanks SD). And the last update for this plugin dealt with exactly this last chapter issue. See here:
http://forum.doom9.org/showthread.php?p=1397341#post1397341
I still tend to believe that it is a MuxMan issue, but in any case removing the last chapter if it lies within the last 50 frames of the movie did solve the issue once and for all. Still I wish that MuxMan wasn't so picky about out-of-range chapters. DVDAuthor just ignores those chapters.
Cheers
manolito
Ghitulescu
18th January 2016, 15:15
If you really need it, you can easily add a blank dummy chapter (with just a single frame) at the end of the PGC with PgcEdit. Use the "Create new cell" button in the PGC Editor.
Thanks, r0LZ. I really appreciate the suggestion, but I am fairly sure that there is something elementary that I am overlooking and can fix.
This is the method used by all commercial DVDs I've seen so far (and offer the possibility to jump right at the end of the movie).
Since the chapter mark has to be associated with at least a VOBU which has to be in a separate cell than the previous VOBU, the demuxers that add the last frame into the celltimes.txt, while useful for other things (like synchronisations etc etc), are not good for remuxing processes (unless one manually removes the last celltime entry).
Richard1485
18th January 2016, 19:20
ChapterGen by shon3i can import a celltimes.txt file with frame numbers (IfoEdit format). You can even specify input- and output frame rates to convert the frame numbers for pulldown.
The app looks handy, but it doesn't seem to be able to convert post-pulldown frame-numbers to pre-pulldown frame-numbers. If I set input to 29.97fps and output to 23.976fps, it returns frame-numbers that are higher not lower.
Never mind! I'll go back to using a spreadsheet, which is what I have been doing up to now.
And the last update for this plugin dealt with exactly this last chapter issue. See here:
http://forum.doom9.org/showthread.php?p=1397341#post1397341
Thank you very much for the link, manolito. The following is from that thread.
Muxman always pushes chapter points forward to the next I-frame (never backwards), and if the source DVD has a chapter within the last GOP, this chapter will be pushed to the next non existent I-frame causing Muxman to fail.
This is the explanation for which I was looking! It explains why MuxMan fails even though the last chapter falls within the movie.
This is the method used by all commercial DVDs I've seen so far (and offer the possibility to jump right at the end of the movie).
Since the chapter mark has to be associated with at least a VOBU which has to be in a separate cell than the previous VOBU, the demuxers that add the last frame into the celltimes.txt, while useful for other things (like synchronisations etc etc), are not good for remuxing processes (unless one manually removes the last celltime entry).
Thanks for the explanation. That makes sense. :)
manono
31st January 2016, 06:12
Just take that last frame number and subtract 20 or so from it. Does it really matter if the last chapter begins a tiny fraction of a second before the end or more than half a second before the end? I've done this for years whenever Muxman gave that "Reference to non-existant scene" message.
Richard1485
3rd February 2016, 12:49
Thanks, manono. It's all sorted now. :-)
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.