Muxman 0.13 released - Page 2

Sir Didymus · 30th March 2005, 11:28

Quote:

Originally posted by mpucoder
btw, if you want a sneak peek at some stuff. Here's a sample of the vm commands syntax that will be used.
And here is the auto generated navigation currently built for you.

Wow!!!

very happy about this info, even though the matter is quickly approaching [or better, it is already beyond...] the limits of my poor knowledge... hope it will be useful to extend it and to learn from your huge work...

For the moment, let me report a little discrepancy [not sure it is a glitch...] between 0.12d and 0.13c.

The project structure is very simple (one m2v, one ac3, 32 chapter points), as follow:

Code:

...[skip]...
Section=Content
{
	Item=Segment
	{
		Name=Segment_1
		Display Mode=Only Letterbox
		Item=Video Stream
		{
			Coding Mode=Mpeg-2
			Standard=PAL
			CC Field 1=No
			CC Field 2=No
			Item=Video Play
			{
				File=E:\JONNY_ENGLISH\demux\VTS01\PGC1\VideoFile.m2v
				Size=3534447192
				Duration=Actual
			}
		}
		Item=Audio Stream
		{
			Stream Number=1
			Language=it
			Language Extension=1
			Delay=0
			Type=04c5
			Frame Size=1536
			Item=Audio Play
			{
				File=E:\JONNY_ENGLISH\demux\VTS01\PGC1\AudioFile_81.ac3
				Size=241439232
			}
		}
		Item=Scene List
		{
			Item=Scene
			{
				Name=Segment_1_scn1
				Scene Time=00:00:00:00
				Uop=00000000
			}

			...[skip]...

			Item=Scene
			{
				Name=Segment_1_scn31
				Scene Time=01:19:31:20
				Uop=00000000
			}
			Item=Scene
			{
				Name=Segment_1_scn32
				Scene Time=01:23:50:00
				Uop=00000000
			}
		}
	}
}

the chapter list is:

Code:

Muxman 0.12d builds up the title without any error.
Muxman 0.13c stops with the following error:
Reference to non-existant scene Segment_1_scn32

I double checked, in the m2v file, the frame nr. 125750 exist (it is the last picture in the stream, a black ending I frame)...

mpucoder · 30th March 2005, 17:41

A single frame is too short to make a chapter. The vobu planner will not allow the last vobu to be split so the frame can be referenced, even if the duration extends it as a still (something I should add), therefore no cell is created.

Look in the log file, there should be no mention of the cell. You could also look at the result from 0.12d with IfoEdit to see how many chapters it created - should be the same. The difference between 0.12 and 0.13 is that 0.12 could ignore scenes (cells) that were not created when building the title PGC because the PGC was built after the multiplex from data produced by the multiplexer (VTS_C_ADT). 0.13 now builds a navigation section in the database that refers to each scene by name before the multiplex.

mpucoder · 30th March 2005, 18:11

@SD - I wanted to try this before posting. A workaround is to get that single frame into another file, add it to the end of the list of files and set its duration to at least 10 frames (PAL, 12 if NTSC). Muxman will then make a cell for the still. You could optionally remove the frame from the original m2v, but that may be more work than it's worth just to prevent seeing the frame twice.

Sir Didymus · 30th March 2005, 18:14

dammit!
You are right, of course...

What a silly question I made!!!
Everybody knows a VOBU can not be shorter than 0.4 s...

I was scratching my head, trying to figure out why the behaviour of Muxman was different from Scenarist...

Taking the opportunity, once more, to thank you for your clarifications. No words are sufficient for the proper appreciation of your big work...

Edit: good idea, to add a still frame at the end, I'll try and report... In my situation it's very easy, being this last frame a black one... CHEERS, SD

Sir Didymus · 30th March 2005, 19:04

@Mpucoder
Your suggestion is working perfectly:

Code:

MuxMan version 0.13c
Accepted video E:\JONNY_ENGLISH\demux\VTS01\PGC1\VideoFile.m2v size = 3534447192
Accepted still E:\JONNY_ENGLISH\demux\VTS01\PGC1\blank.m2v size = 6529
Accepted audio E:\JONNY_ENGLISH\demux\VTS01\PGC1\AudioFile_81.ac3
Opened sub 1 file E:\JONNY_ENGLISH\demux\VTS01\PGC1\Subpictures_20.sup.
Opened sub 2 file E:\JONNY_ENGLISH\demux\VTS01\PGC1\Subpictures_21.sup.
Opened sub 3 file E:\JONNY_ENGLISH\demux\VTS01\PGC1\Subpictures_22.sup.
Opened sub 4 file E:\JONNY_ENGLISH\demux\VTS01\PGC1\Subpictures_23.sup.
Opened sub 5 file E:\JONNY_ENGLISH\demux\VTS01\PGC1\Subpictures_24.sup.
expanded database to 116 entries.
expanded database to 132 entries.
expanded database to 148 entries.
expanded database to 164 entries.
expanded database to 180 entries.
expanded database to 196 entries.
expanded database to 212 entries.
18:35:28 Begin multiplex.
Maximum audio duration 251498 fields.
Starting scene Segment_1_scn1 at 00:00:00:00
...skip...
Starting scene Segment_1_scn23 at 00:55:44:11
Starting scene Segment_1_scn24 at 00:56:01:06, requested for 00:56:00:19
Starting scene Segment_1_scn25 at 00:59:46:18
Starting scene Segment_1_scn26 at 01:02:19:09, requested for 01:02:18:22
Starting scene Segment_1_scn27 at 01:06:05:11
Starting scene Segment_1_scn28 at 01:10:08:03
Starting scene Segment_1_scn29 at 01:14:51:12
Starting scene Segment_1_scn30 at 01:17:59:16
Starting scene Segment_1_scn31 at 01:19:31:20
SeqEnd at D2AB6254.
Starting scene Segment_1_scn32 at 01:23:50:01, requested for 01:23:50:00
SeqEnd at 197D.
Bytes remaining in buffer = 0.
18:43:54 End multiplex.
Bitrate - avg: 6146279, min: 368640 (lba 1887106), max: 9284266 (lba 714261).
Shortest GOP has 2 fields, longest GOP has 24 fields.
Fields: 251522, Still fields: 18, VOBU: 10169, Sectors: 1887115.

By the way, looking at the Muxman log, I see sometimes it still happen that the user request for a given chapter point is disregarded [delayed by one GOP]. One of the bad consequences is that the presence of subpictures starting at the beginning of a given chapter tends to produce a "flickering" of the subtitles: normally subtitles are 3 seconds or more, so in the condition of a delayed chapter start, the subpicture start at the very end of the previous chapter and quickly disappear (after one GOP) at the start of the actual chapter point. I hope it is clear what I mean: for this specific situation, in case it's impossible to respect the requested chapter starts, it may be better to try to "anticipate" the chapters, instead than delay them...

Do you have any hint in order to cope with this type of problems ?

All the best,
SD

mpucoder · 30th March 2005, 19:46

I think for now it would be better to determine the reason the chapter point requests were not honored. I know this is some work, but I need to know the lengths of the 4 gops preceeding the missed chapter. An easy way is to make note of the vobu_s_ptm (offset 0039 in nac pack) for 2 or 3 vobu preceeding the chapter and how many gop headers there were in each. The logic is not perfect, I have several theoretical and supposedly rare cases in my notes - now I need to know if theory is reality.

Also looks like I need to "grow" the database in larger steps.

Sir Didymus · 30th March 2005, 20:31

Quote:

Originally posted by mpucoder
...I need to know the lengths of the 4 gops preceeding the missed chapter. An easy way is to make note of the vobu_s_ptm (offset 0039 in nav pack) for 2 or 3 vobu preceeding the chapter ...

That's easy to do, if you think it may be useful; just need to use VobEdit; all the files are available to me, so it'll take very little time...

Quote:

...and how many gop headers there were in each...

How many GOP headers in each VOBU ?
Am I missing something ?
That sounds less obvious to me...
The only way I see is to parse the VOBs with a specific program...
Maybe it is sufficient just to count the number of I frames in each VOBU [again, just using VobEdit] ?

Edit: Ok. Got it. Again with VobEdit, it is the "GOP start code...". I'll collect the info and report tomorrow...

mpucoder · 30th March 2005, 20:53

In the left pane of VobEdit it shows [GOP] whenever there is a new gop.

Actually the pts information isn't the best to gather, it would be better to count frame headers in each gop - again VobEdit shows [I], [P], or [B] for each frame (sometimes multiple frames in one pack, they look like [BB] )

Sir Didymus · 31st March 2005, 09:49

Following link point to an xls file useful as a reference:
http://webmail.libero.it/r.php?d=lib...px3bw9OK103177

It is valid until 07.04.2005 09:06AM.

Well, I spent very little time to do coreographic improvements to the document; indeed hope collected info is still readable.

It clarifies (a little bit) what happened...
For example, in the chapter 84031, requested for 84019, the VOBU structures are as follow:

Code:

VOBU #  VOBU Structure                   VOBU Size (pictures)
+1      [GOP]IBBPBBPBB[GOP]IBBPBB        15
0       [GOP]IBBPBBPBBPBB                12
-1      [GOP]IBBPPPBP[GOP]IPBPBBPBBPBB   20
-2      [GOP]IBBPBBPBBPBB                12
-3      [GOP]IBBPBBPBBPBB                12
-4      [GOP]IBBPBBPBBPBB                12

It seems the chapter request has not been accepted since the previous GOP, being just 8 pictures long, would produce (alone) a VOBU shorter than 0.4 s.
In this case maybe the proper strategy would be to check if this short GOP may be joined to the previous VOBU (the one at # -2)...

I see no visible drawbacks in this case...

The second example (chapter point 93472, requested for 93484) is even more interesting, since the first "available" VOBU is at # -3...

All the best,
SD

Edit: Hmmm. I have an update on this test (it's not a good news, I'd say): trying to replicate the problem on a shorter segment, I extracted the two cells from the title, across to the first disregarded chapter point (using VobEdit, it produced two vob files). Then joined (copy /B) the two cells, obtaining a single vob file. then demuxed ALL of the contained assets and remuxed with MuxMan a new title, using a single chapter point exactely matching the original one...

In this test the chapter point has been accepted, so it seems the GOP structure of the pictures across to the chapter point is not the (principal) factor causing the un-acceptance of the chapter points...

So apparently the condition/s causing this behaviour is/are not easily replicatable...

mpucoder · 31st March 2005, 16:36

So vobu 0 is where the chapter was made? The strategy you describe (of joining the 8 frame gop to the previous 12 frame to align the chapter point) is exactly what Muxman is supposed to do. I don't understand why it did not. This is PAL, right?

Sir Didymus · 31st March 2005, 16:53

So vobu 0 is where the chapter was made? --> yes...
This is PAL, right? --> yes... I double cheched the PTS values, in order to guarantee not to report mistakes about the GOP structures and picture nr... [there are some notes in the xls file reporting the values], each picture takes 40 ms...

mpucoder · 31st March 2005, 16:56

I don't have any program to view xls

(not really sure I want one either)

Sir Didymus · 31st March 2005, 17:24

Oh, I see...

Well, no problem, here it is the code for the second delayed chapter point:

Code:

VOBU #  VOBU Structure                   VOBU Size (pictures)
+1      [GOP]IBBPBBPBBPBB                12
0       [GOP]IBBPBBPBBPBB                12
-1      [GOP]IPBPB[GOP]IPBPBBPBBPBB      17
-2      [GOP]IBBPBBPBB[GOP]IBBPBBPBBPB   20
-3      [GOP]IBBPBBPBBPBB                12
-4      [GOP]IBBPBBPBBPBB                12

Just for the additional info, here it is the picture of the xls...
...best to save the image on the local PC and to look at it in its original resolution...

mpucoder · 31st March 2005, 18:03

Thanks for the gif. I can see what went wrong with the second one - at least enough to know what math to check. But the first one bothers me as it is a simple case that was tested. The logic for this case is "if the current vobu meets minimum and the next gop is short (<400ms) and the distance to the next chapter is short, incorporate the next gop into the current vobu" (this is not the only rule, just the one that applies to this case)
So when it is the vobu starting at 83998 the conditions are:
vobu length 12 frames (meets minimum)
next gop (which starts at 84010) is 9 frames (short)
next chapter is 9 frames later (short)
I should have joined the 9 frame gop and placed the chapter correctly.
But I'll double check the math.

I can synthesize an m2v with these gop lengths unless you happen to have the files already.

mpucoder · 31st March 2005, 22:22

A new Muxman (0.13d) to fix subpicture attributes in VTSI_MAT is now available at the Muxman homepage

Sir Didymus · 1st April 2005, 17:15

Quote:

Originally posted by mpucoder
...
I can synthesize an m2v with these gop lengths unless you happen to have the files already...

I keep the files, and of course I will not delete them, at least for a while, for testing purposes.

Funny thing is that I spent really a lot of time trying to reduce their size, in order to make possible to share some segment... but all my attempts to reproduce the problem are being frustrated...

I mean, the problem is replicatable (on the same huge 3GB m2v file), even remuxing it without audio and subpicures: giving to MuxMan 0.13d the m2v and the chapter list generates every time exactely the two glitches previously reported...

If I try to reduce in some way the m2v size, cutting out for example the first cell of the m2v, and adjusting in a suitable way the chapter list, the problem disappears...

Sorry, but in this condition I have no cues on the matter...

Very strange indeed; I'd say while being not able to replicate in a short segment the reported behaviour, my posts are almost un-useful...

So, nice w/e for the moment...

mpucoder · 1st April 2005, 17:21

Here's what we can do then, since I cannot duplicate the problem either. Make a profile using Muxman 0.11c - it's the last version to have the "make profile" checkbox, and available in my forum archives in case you deleted it. Don't worry about what 0.11c makes for a DVD, profile information allows me to synthesize the entire m2v file.

CoNS · 1st April 2005, 19:22

I have two bug reports and a request...

First bug report: I'm trying to mux a disc where I get this error every time I try it with MuxMan:

See this picture: http://home25.inet.tele.dk/dvdkat/muxman1.png

It happens at 99% in the muxing process. In the output folder, all files have been created by MuxMan except VIDEO_TS.IFO and .BUP. The created .vob files have the correct sizes, but are not playable.

IfoEdit does the job without any warnings or errors, and the output plays fine. I've used PgcDemux latest version to demux streams (only 1 video, 1 audio and 1 subtitle stream) and create celltimes.txt. MuxMan reads 13 chapters from the celltimes.txt file, but the original movie only shows 12 chapters in my software player (Media Player Classic). Same with the output created by IfoEdit.

Second bug report: It's possible to click [...] (browse) for audio 1, click "Cancel" in the browser window and then still get to the stream arrangement window. If I then click "Close" in this window, I return to the main MuxMan window, now with the browse button for audio 2 available. If I then select an audio file for the second slot (still leaving the first slot blank), and fill out all other information about the other streams etc. and hit "Start", Windows (Win2000) gives me a standard error message and closes MuxMan.

And then my request: I know I've asked this before, please forgive me for repeating it!

But I'm not into Scenarist scripts and I think it would be extremely nice to have a function below the "Import Chapters" function in the File menu called "Import subtitle colours", which would bring up a browse window looking for an .ifo file and then let you specify a PGC within that titleset to copy subtitle colours from and use in the MuxMan process. Kinda like ReJig's authoring function combined with the PGC selection from PgcDemux... Please? Pretty please with sugar on the top?!!

mpucoder · 1st April 2005, 19:40

The first one is not a bug, and was explained. In the past Muxman would ignore chapters that could not be created because they either were too close to the previous chapter (less than 400ms, 10 PAL or 12 NTSC frames) or beyond the end of the segment. It now considers these fatal errors as the condition makes it impossible to compile the ifo files.

The second one I'm aware of and once the project is a little futher on a as yet unwritten process of planning the entire DVD will fix this.

Muxman is an authoring program, and the project's goal is to achieve full authoring capability. While I can make a few concessions to re-authoring (such as .sup files or fixing SubRip .sst files), anything as major as extracting information from already authored DVDs is a side trip I'm not willing to make until the main goal has been reached.

Editing a palette is not that difficult. Create your project with the gui, save the project to a file, edit the file with notepad, and then load the file back in.

CoNS · 1st April 2005, 19:45

Quote:

Originally posted by mpucoder
The first one is not a bug, and was explained. In the past Muxman would ignore chapters that could not be created because they either were too close to the previous chapter (less than 400ms, 10 PAL or 12 NTSC frames) or beyond the end of the segment. It now considers these fatal errors as the condition makes it impossible to compile the ifo files.

What do I do to fix it then?

30th March 2005, 18:14	#24 \| Link
Sir Didymus Registered User Join Date: Mar 2004 Location: Italy Posts: 864	dammit! You are right, of course... What a silly question I made!!! Everybody knows a VOBU can not be shorter than 0.4 s... I was scratching my head, trying to figure out why the behaviour of Muxman was different from Scenarist... Taking the opportunity, once more, to thank you for your clarifications. No words are sufficient for the proper appreciation of your big work... Edit: good idea, to add a still frame at the end, I'll try and report... In my situation it's very easy, being this last frame a black one... CHEERS, SD Last edited by Sir Didymus; 30th March 2005 at 18:19.

31st March 2005, 09:49	#29 \| Link
Sir Didymus Registered User Join Date: Mar 2004 Location: Italy Posts: 864	Following link point to an xls file useful as a reference: http://webmail.libero.it/r.php?d=lib...px3bw9OK103177 It is valid until 07.04.2005 09:06AM. Well, I spent very little time to do coreographic improvements to the document; indeed hope collected info is still readable. It clarifies (a little bit) what happened... For example, in the chapter 84031, requested for 84019, the VOBU structures are as follow: Code: VOBU # VOBU Structure VOBU Size (pictures) +1 [GOP]IBBPBBPBB[GOP]IBBPBB 15 0 [GOP]IBBPBBPBBPBB 12 -1 [GOP]IBBPPPBP[GOP]IPBPBBPBBPBB 20 -2 [GOP]IBBPBBPBBPBB 12 -3 [GOP]IBBPBBPBBPBB 12 -4 [GOP]IBBPBBPBBPBB 12 It seems the chapter request has not been accepted since the previous GOP, being just 8 pictures long, would produce (alone) a VOBU shorter than 0.4 s. In this case maybe the proper strategy would be to check if this short GOP may be joined to the previous VOBU (the one at # -2)... I see no visible drawbacks in this case... The second example (chapter point 93472, requested for 93484) is even more interesting, since the first "available" VOBU is at # -3... All the best, SD Edit: Hmmm. I have an update on this test (it's not a good news, I'd say): trying to replicate the problem on a shorter segment, I extracted the two cells from the title, across to the first disregarded chapter point (using VobEdit, it produced two vob files). Then joined (copy /B) the two cells, obtaining a single vob file. then demuxed ALL of the contained assets and remuxed with MuxMan a new title, using a single chapter point exactely matching the original one... In this test the chapter point has been accepted, so it seems the GOP structure of the pictures across to the chapter point is not the (principal) factor causing the un-acceptance of the chapter points... So apparently the condition/s causing this behaviour is/are not easily replicatable... Last edited by Sir Didymus; 31st March 2005 at 15:49.

31st March 2005, 16:53	#31 \| Link
Sir Didymus Registered User Join Date: Mar 2004 Location: Italy Posts: 864	So vobu 0 is where the chapter was made? --> yes... This is PAL, right? --> yes... I double cheched the PTS values, in order to guarantee not to report mistakes about the GOP structures and picture nr... [there are some notes in the xls file reporting the values], each picture takes 40 ms... Last edited by Sir Didymus; 31st March 2005 at 16:56.

31st March 2005, 17:24	#33 \| Link
Sir Didymus Registered User Join Date: Mar 2004 Location: Italy Posts: 864	Oh, I see... Well, no problem, here it is the code for the second delayed chapter point: Code: VOBU # VOBU Structure VOBU Size (pictures) +1 [GOP]IBBPBBPBBPBB 12 0 [GOP]IBBPBBPBBPBB 12 -1 [GOP]IPBPB[GOP]IPBPBBPBBPBB 17 -2 [GOP]IBBPBBPBB[GOP]IBBPBBPBBPB 20 -3 [GOP]IBBPBBPBBPBB 12 -4 [GOP]IBBPBBPBBPBB 12 Just for the additional info, here it is the picture of the xls... ...best to save the image on the local PC and to look at it in its original resolution... Last edited by Sir Didymus; 31st March 2005 at 17:26.

31st March 2005, 18:03	#34 \| Link
mpucoder Moderator Join Date: Oct 2001 Posts: 3,398	Thanks for the gif. I can see what went wrong with the second one - at least enough to know what math to check. But the first one bothers me as it is a simple case that was tested. The logic for this case is "if the current vobu meets minimum and the next gop is short (<400ms) and the distance to the next chapter is short, incorporate the next gop into the current vobu" (this is not the only rule, just the one that applies to this case) So when it is the vobu starting at 83998 the conditions are: vobu length 12 frames (meets minimum) next gop (which starts at 84010) is 9 frames (short) next chapter is 9 frames later (short) I should have joined the 9 frame gop and placed the chapter correctly. But I'll double check the math. I can synthesize an m2v with these gop lengths unless you happen to have the files already. Last edited by mpucoder; 31st March 2005 at 18:11.

30th March 2005, 17:41	#22 \| Link
mpucoder Moderator Join Date: Oct 2001 Posts: 3,398	A single frame is too short to make a chapter. The vobu planner will not allow the last vobu to be split so the frame can be referenced, even if the duration extends it as a still (something I should add), therefore no cell is created. Look in the log file, there should be no mention of the cell. You could also look at the result from 0.12d with IfoEdit to see how many chapters it created - should be the same. The difference between 0.12 and 0.13 is that 0.12 could ignore scenes (cells) that were not created when building the title PGC because the PGC was built after the multiplex from data produced by the multiplexer (VTS_C_ADT). 0.13 now builds a navigation section in the database that refers to each scene by name before the multiplex.

30th March 2005, 18:11	#23 \| Link
mpucoder Moderator Join Date: Oct 2001 Posts: 3,398	@SD - I wanted to try this before posting. A workaround is to get that single frame into another file, add it to the end of the list of files and set its duration to at least 10 frames (PAL, 12 if NTSC). Muxman will then make a cell for the still. You could optionally remove the frame from the original m2v, but that may be more work than it's worth just to prevent seeing the frame twice.

30th March 2005, 19:46	#26 \| Link
mpucoder Moderator Join Date: Oct 2001 Posts: 3,398	I think for now it would be better to determine the reason the chapter point requests were not honored. I know this is some work, but I need to know the lengths of the 4 gops preceeding the missed chapter. An easy way is to make note of the vobu_s_ptm (offset 0039 in nac pack) for 2 or 3 vobu preceeding the chapter and how many gop headers there were in each. The logic is not perfect, I have several theoretical and supposedly rare cases in my notes - now I need to know if theory is reality. Also looks like I need to "grow" the database in larger steps.

30th March 2005, 20:53	#28 \| Link
mpucoder Moderator Join Date: Oct 2001 Posts: 3,398	In the left pane of VobEdit it shows [GOP] whenever there is a new gop. Actually the pts information isn't the best to gather, it would be better to count frame headers in each gop - again VobEdit shows [I], [P], or [B] for each frame (sometimes multiple frames in one pack, they look like [BB] )

31st March 2005, 16:36	#30 \| Link
mpucoder Moderator Join Date: Oct 2001 Posts: 3,398	So vobu 0 is where the chapter was made? The strategy you describe (of joining the 8 frame gop to the previous 12 frame to align the chapter point) is exactly what Muxman is supposed to do. I don't understand why it did not. This is PAL, right?

31st March 2005, 16:56	#32 \| Link
mpucoder Moderator Join Date: Oct 2001 Posts: 3,398	I don't have any program to view xls (not really sure I want one either)

31st March 2005, 22:22	#35 \| Link
mpucoder Moderator Join Date: Oct 2001 Posts: 3,398	A new Muxman (0.13d) to fix subpicture attributes in VTSI_MAT is now available at the Muxman homepage

1st April 2005, 17:21	#37 \| Link
mpucoder Moderator Join Date: Oct 2001 Posts: 3,398	Here's what we can do then, since I cannot duplicate the problem either. Make a profile using Muxman 0.11c - it's the last version to have the "make profile" checkbox, and available in my forum archives in case you deleted it. Don't worry about what 0.11c makes for a DVD, profile information allows me to synthesize the entire m2v file.

1st April 2005, 19:22	#38 \| Link
CoNS reMember Join Date: Oct 2004 Location: Under your bed Posts: 729	I have two bug reports and a request... First bug report: I'm trying to mux a disc where I get this error every time I try it with MuxMan: See this picture: http://home25.inet.tele.dk/dvdkat/muxman1.png It happens at 99% in the muxing process. In the output folder, all files have been created by MuxMan except VIDEO_TS.IFO and .BUP. The created .vob files have the correct sizes, but are not playable. IfoEdit does the job without any warnings or errors, and the output plays fine. I've used PgcDemux latest version to demux streams (only 1 video, 1 audio and 1 subtitle stream) and create celltimes.txt. MuxMan reads 13 chapters from the celltimes.txt file, but the original movie only shows 12 chapters in my software player (Media Player Classic). Same with the output created by IfoEdit. Second bug report: It's possible to click [...] (browse) for audio 1, click "Cancel" in the browser window and then still get to the stream arrangement window. If I then click "Close" in this window, I return to the main MuxMan window, now with the browse button for audio 2 available. If I then select an audio file for the second slot (still leaving the first slot blank), and fill out all other information about the other streams etc. and hit "Start", Windows (Win2000) gives me a standard error message and closes MuxMan. And then my request: I know I've asked this before, please forgive me for repeating it! But I'm not into Scenarist scripts and I think it would be extremely nice to have a function below the "Import Chapters" function in the File menu called "Import subtitle colours", which would bring up a browse window looking for an .ifo file and then let you specify a PGC within that titleset to copy subtitle colours from and use in the MuxMan process. Kinda like ReJig's authoring function combined with the PGC selection from PgcDemux... Please? Pretty please with sugar on the top?!!

1st April 2005, 19:40	#39 \| Link
mpucoder Moderator Join Date: Oct 2001 Posts: 3,398	The first one is not a bug, and was explained. In the past Muxman would ignore chapters that could not be created because they either were too close to the previous chapter (less than 400ms, 10 PAL or 12 NTSC frames) or beyond the end of the segment. It now considers these fatal errors as the condition makes it impossible to compile the ifo files. The second one I'm aware of and once the project is a little futher on a as yet unwritten process of planning the entire DVD will fix this. Muxman is an authoring program, and the project's goal is to achieve full authoring capability. While I can make a few concessions to re-authoring (such as .sup files or fixing SubRip .sst files), anything as major as extracting information from already authored DVDs is a side trip I'm not willing to make until the main goal has been reached. Editing a palette is not that difficult. Create your project with the gui, save the project to a file, edit the file with notepad, and then load the file back in.

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode