Muxman 0.13 released

[mpucoder]

A great deal of work has gone into changing Muxman ifo generation from a simple "canned" set of tables to being compiled from a database. Unfortunately, the work isn't complete enough to allow the Navigation section to be user defined.

But this release does have 3 improvements:
Definable subpicture palette
Improved I-Frame encoder
Frame-accurate chapters (provided the chapter begins on an I frame)

Available from the Muxman homepage (http://www.mpucoder.com/Muxman/)

Please consult the mxp documentation (http://www.mpucoder.com/Muxman/mxp/index.html) especially the new Settings Section (http://www.mpucoder.com/Muxman/mxp/settings.html)

[D3s7]

Excellent advancements.... It won't be long before Scenarist is obsolete for what we need it for :)

Question: Will there be support to specify channels for audio/subtitles that's out of order.. IE: audio 1 = 84.

Scenarist requires you dummy 80-83 in order to do that.

Thanks

- D3s7

[mpucoder]

Scenarist is just enforcing the specs, audio and subpicture stream numbers should be consecutive. Right now, and for the foreseeable future, Muxman will not allow manual stream assignments. When it does the specs will still be enforced by some mechanism.
At present, with only one title, the audio and subpicture stream numbers follow the value in the scp or mxp file. But once Muxman starts working with multiple titles per titleset the script file stream numbers will be relative to each segment, but not necessarily the same as the titleset. This will happen if two titles have different requirements, e.g. title 1 has one audio stream of 5.1 DD, while title 2 has one audio stream of 2.0 DD.

But - it should not be necessary to skip stream numbers. There are 2 places where absolute numbers, rather than symbolic names, are used in scripts. One is line numbers for the "goto" command. Muxman changes the way commands are defined into what resembles assembler source, complete with labels.
The other place where numbers are used is to specify a "stream" in the SetSTN command. I prefer to call this a track, as it is the number used to index a table in the PGC which then supplies the actual stream number. This number remains the same even if stream numbers are reassigned.

[D3s7]

Understood... and I'm not sure the attraction to it for authoring houses

The problem we run into in Scenarist is when a particular PGC/VOBID uses different stream assignments from the rest of the Title. Scenarist won't except those for mux (as can be understood) forcing us to dummy the appropriate streams. Not really a problem for PGC demuxes but for VOBID demuxes it can be an issue for Seamless cells


Seems more and more the DVD "Specs" are more "Recommended guidelines but feel free to break if you wish" :)

[mpucoder]

Are you saying that there are titles which have one or more Vobs with different stream numbers than the rest of the title? This makes little sense - how does the player access a stream that suddenly appears in the middle of a title. As far as I know, and this is how I planned to implement in Muxman, all the segments (or "tracks" in Scenarist) must have the same video attributes, and have the same number and type of audio/sub streams.

I can understand a segment using different streams than others in the same titleset, this is commonl. Not in the same title, though, but a seperate title.

[D3s7]

unfortunatly, yes...

a few have "additional" audio tracks in one PGC -vs- another (same VOBID) - Finding Nemo for example, 80,81,82
PGC 1 uses 80,82 - PGC 2 uses 81 (example - not sure if that's the correct mapping) - demuxing this by vobid isn't an issue but 81 must be dummied on other assets in that PGC.

that's just one example but I've run across 4 or 5 movies like that. The problem is in order to dummy 81 across the other vobid's causes the cells to have to be linked non-seamless... Currently one of the solutions is to flip 82 and 81 so you have 80,81 on the main and the "extra" pgc uses 82

[mpucoder]

Is this the R1 version? I'm not into buying animated movies (or G ratings - btw, why won't my V chip block the teletubbies, I want ONLY R!), but in this case I could make an exception if it demonstrates a DVD oddity.

[D3s7]

I've got 3 still files that I use for Scenarist that when trying to import them into Muxman 13 (tried 12 as well) it locks the interface hard... have to kill the process to get out of it.

Want me to email them to you?

[mpucoder]

sure - muxman (at) mpucoder (dot) com (have to type it this way or I get a flood of email in Korean - have no idea what they're selling)

[sweetness]

when i mux only a bmp or a m2v file(no audio no subs) muxman crashes(encountered an error message). ifoedit reports that there is no titleset tables when i do a get vts sectors(no video_ts.ifo is created)

in version 11c it muxed everything and the operation compete window pops up but muxman close once ok is pressed. ifoedit does not complain.

[mpucoder]

What is the error message? What version of Windows? What does the Muxman log say?

[sweetness]

the microsoft "MunxMan.exe has encountered a problem and needs to close. We are sorry for the inconvenience."

win xp sp2

it crashes once the progress bar is done.

tried v.12c and it does the same thing as v.11 it closes once ok is pressed.
v.13 crash all the time now with audio or not.:(

[D3s7]

Originally posted by sweetness
when i mux only a bmp or a m2v file(no audio no subs) muxman crashes(encountered an error message). ifoedit reports that there is no titleset tables when i do a get vts sectors(no video_ts.ifo is created)

in version 11c it muxed everything and the operation compete window pops up but muxman close once ok is pressed. ifoedit does not complain.

I noted this issue myself and partially tracked it down to the installed version of comdlg32.dll....

version 6.0.2900.xxx seems to work fine where as 6.0.2800.xxx doesn't.
I was only able to test this theory on one machine but upgrading the dll seemed to resolve the issue - i assumed the newer dll was from xp sp2 but it may be from the .net 2003 extensions as well....

[mpucoder]

I'm fairly certain this bug has been squashed by version 0.13c

@sweetness - Muxman is supposed to close when you click OK. That will probably change in the future when I'm certain that the program can run project after project without problems.

[sweetness]

thanks tried out .13c and seems to work good.
also notice some dummy menus.:)

BTW creating 16:9 stills Display Mode=Only Pan Scan doesn't work, muxman displays 4:3. but P/S and LB or Only Letterbox works.

[Sir Didymus]

Just to confirm 0.13c have solved the issue: no need to upgrade comdlg32.dll...

All the best,
SD

[Zeul]

@SD
Are you working from a mxp project file? I have noticed that 0.13 has changed the scripting for pan. It was Display Mode=Only Pan Scan -> it is now Display Mode=Only Panscan.

[sweetness]

@Zeul
yes thank you. i even check the site too, but missed that the space was gone.
oh ya wrong guy.:) that's ok i get that all the time.

[mpucoder]

That's true, I changed some keywords to be the same as Scenarist.

video display mode Only Pan Scan changed to Only Panscan (as noted above)

subpicture display mode PS changed to Pan in all combinations (Pan, Letter/Pan, Wide/Pan, Wide/Letter/Pan

Sorry for not drawing more attention to that. Also Uop can be specified in scenes (but not put into the vob - oops)

[mpucoder]

btw, if you want a sneak peek at some stuff. Here's a sample of the vm commands (http://www.mpucoder.com/Muxman/alpha/cmd_sample_mxp.txt) syntax that will be used.
And here is the auto generated navigation (http://www.mpucoder.com/Muxman/alpha/autogen_mxp.txt) currently built for you.

[Sir Didymus]

Originally posted by mpucoder
btw, if you want a sneak peek at some stuff. Here's a sample of the vm commands (http://www.mpucoder.com/Muxman/alpha/cmd_sample_mxp.txt) syntax that will be used.
And here is the auto generated navigation (http://www.mpucoder.com/Muxman/alpha/autogen_mxp.txt) 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:


...[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:

5628
11784
20268
25671
32391
37984
38368
38488
41308
41860
46755
47127
48267
56391
63925
67165
67993
68293
70621
77911
82891
83611
84019
89668
93472
99136
105203
112287
116991
119295
125750

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]

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]

@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]

:)
dammit!
You are right, of course... :scared:

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]

@Mpucoder
Your suggestion is working perfectly:


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]

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]

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...

...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]

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]

Following link point to an xls file useful as a reference:
http://webmail.libero.it/r.php?d=libero.it&wr=3zqcxucf&ws=3zqcxucf&e=libero.it&c=gW6ZnOnV7n6LHtTn5RaaThnopx3bw9OK103177

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:


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]

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]

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]

I don't have any program to view xls :( (not really sure I want one either)

[Sir Didymus]

Oh, I see...

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


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...

http://img191.exs.cx/img191/6613/xls9kw.th.gif (http://img191.exs.cx/my.php?loc=img191&image=xls9kw.gif)

[mpucoder]

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]

A new Muxman (0.13d) to fix subpicture attributes in VTSI_MAT is now available at the Muxman homepage (http://www.mpucoder.com/Muxman/)

[Sir Didymus]

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... :confused:

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]

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]

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?!! :D

[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.

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]

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?

[mpucoder]

If you are using scp or mxp the scene name tells you which one was not created.
If you are using a chapter list look at the scene name in the error message, it always ends with a number. The number is the chapter number that was not created. In your case the 13th chapter.

[CoNS]

So I just open my celltimes.txt file in notepad and delete the last chapter manually?

About the colour palette: Does the project file operate with YCrCB colour values or RGB?

[mpucoder]

Originally posted by CoNS
So I just open my celltimes.txt file in notepad and delete the last chapter manually?If that is the 13th chapter, yes.

About the colour palette: Does the project file operate with YCrCB colour values or RGB? RGB

[Sir Didymus]

Originally posted by mpucoder
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.

Excellent!!! Just done and sent to your e-mail the mxl file...

[mpucoder]

I found the problem, and there will be a new version soon. Just so you know why it changed when you modified the m2v, vobu planning uses random access to the video file, and the standard seek function uses a 32-bit signed integer for file position. Therefore it cannot be used to position beyond 2GB, and leaves the file at its current position. This means that the problems only happened beyond 2GB.

[mpucoder]

OK, version 0.13e is now available at the Muxman homepage (http://www.mpucoder.com/Muxman/)
Fixes two problems:
some bmp files not being decoded properly
chapter points beyond 2GB in the video file were not always at the correct frame.

[Sir Didymus]

Confirming in my test 0.13e solved the glitch on the chapter points...
Very subtile and difficult to catch, this one...

Compliments!!!
SD

[Trahald]

@mpucoder

yeah.. fseek bit me in the --- with some stuff i added to pulldown.exe.

_fseeki64 works alot better.

[DMagic1]

I have 4 seperate m2v files I'm adding in. All except one is accepted.
If I add that one first its accepted but all others after it are rejected. If I add the others first then that same one gets rejected. :confused:

[mpucoder]

All the files must have the same attributes like resolution, aspect ratio, framerate, pan/scan data, and CC. The log gives you a code for why the file was rejected. You can also open just one video file and look at the line under the filename on the main gui to see its attributes.

[Paulcat]

I's like to second CoNs request for a subtitle colour import. I know you mentioned in another post that the default palette for MuxMan is the same as it is for Scenarist...well not owning a copy of Scenarist leaves me a bit in the dark (I am using Subtitle Creator to make my bitmaps and tending to see only black and white) so I was wondering if you or someone else in the know can tell be what the default colours are, this way I can continue to be lazy and not have to pull colours from other IFO files with IFOEdit...

Of course I assume eventually you will have a palette editor in MuxMan...

[mpucoder]

The easy way to see the default palette is to save a project with Muxman, even an empty one, then look at the project file.

[SeeMoreDigital]

Can somebody remind me how to input the chapter listings please?

DVDdecrypter offers the following options: -CCE: -

chapter=0:
chapter=6508:
chapter=11114:
chapter=14496:
chapter=18831:
-------------------------------------------------------------------------------------------
DVDLab: -

00:00:00:000
00:04:20:000
00:07:24:000
00:09:39:000
00:12:33:000
-------------------------------------------------------------------------------------------
IfoEdit: -

6508
11114
14496
18831
22315
-------------------------------------------------------------------------------------------
LBA: -

CHAPTER_01:VTS_02_1 - 0xE0 - Video - MPEG-2 - 720x576 (PAL) - 16~9 - Letterboxed.M2V:0
CHAPTER_02:VTS_02_1 - 0xE0 - Video - MPEG-2 - 720x576 (PAL) - 16~9 - Letterboxed.M2V:79291
CHAPTER_03:VTS_02_1 - 0xE0 - Video - MPEG-2 - 720x576 (PAL) - 16~9 - Letterboxed.M2V:123554
CHAPTER_04:VTS_02_1 - 0xE0 - Video - MPEG-2 - 720x576 (PAL) - 16~9 - Letterboxed.M2V:161018
CHAPTER_05:VTS_02_1 - 0xE0 - Video - MPEG-2 - 720x576 (PAL) - 16~9 - Letterboxed.M2V:206059
-------------------------------------------------------------------------------------------
OGG: -

CHAPTER01=00:00:00.000
CHAPTER01NAME=Chapter 1
CHAPTER02=00:04:20.320
CHAPTER02NAME=Chapter 2
CHAPTER03=00:07:24.560
CHAPTER03NAME=Chapter 3
CHAPTER04=00:09:39.840
CHAPTER04NAME=Chapter 4
CHAPTER05=00:12:33.240
CHAPTER05NAME=Chapter 5
-------------------------------------------------------------------------------------------
Scenarist: -

00:00:00;00
00:04:20;08
00:07:24;14
00:09:39;21
00:12:33;06
-------------------------------------------------------------------------------------------
DVDMaestro: -

$Spruce_IFrame_List

00:00:00:00
00:04:20:08
00:07:24:14
00:09:39:21
00:12:33:06
-------------------------------------------------------------------------------------------
BSPlayer: -

[CHAPTERS]
1=0 Chapter 1
2=6508 Chapter 2
3=11114 Chapter 3
4=14496 Chapter 4
5=18831 Chapter 5Can any of them be used with MuxMan?


Cheers

[bourtzovlakas]

The IfoEdit way, definitely works....
I am not sure about the others....

[SeeMoreDigital]

Originally posted by bourtzovlakas
The IfoEdit way, definitely works....
I am not sure about the others.... So MuxMan is frame number based only!

Thanks... I had forgot this.


Cheers

[CoNS]

mpucoder, about the subtitle colours: r0lZ also thought it was too much of a hassle to implement a function in PgcEdit to parse all PGCs in an .ifo and to let the user select the relevant PGC to copy the colours from.

However, he has now added an import/export subtitle colour function in the latest version of PgcEdit (v0.5.2beta2), which add an export and an import button in the color lookup table editor, so that you will be able to save the color table, and reuse it whenever you need it.

The new function loads/saves the raw, unmodified color table in binary, as it is stored in the IFO (64 YCrCb bytes - the first byte of each color is a null, pad byte) with a .CLB file extension ("PGC Color Lookup Table" file).

It would be really great if you would add a "Import subtitle colours" function in MuxMan (right below the "Import Chapters" function in File menu) which simply loads such a .CLB file and uses the colours for the project. Please? As you can see, more users would find such a function very useful, it's not just me who keeps buggin' ya! :D

EDIT: The latest beta of PgcEdit is available via the "All Versions" link of the PgcEdit homepage at VideoHelp (http://www.videohelp.com/~r0lZ/pgcedit/).

[Paulcat]

Originally posted by mpucoder
The easy way to see the default palette is to save a project with Muxman, even an empty one, then look at the project file.
Or, open IFOEdit and check it out from there. Thanks for the reply, but I think my problems are arising in Subtitle Creator...

[stickboy]

Originally posted by Paulcat
Originally posted by mpucoder
The easy way to see the default palette is to save a project with Muxman, even an empty one, then look at the project file.Or, open IFOEdit and check it out from there. Thanks for the reply, but I think my problems are arising in Subtitle Creator...The IFOEdit way will give you YCbCr values, whereas looking at Muxman's .mxp file will show you RGB ones.

[D3s7]

Just a note to all in NTSC land using muxman...

If you use a pulled down asset for muxman, it does the opposite w/ .5 frames as scenarist

Scenarist appends the missing field and add's the frame, muxman drops the extra field and uses the last full frame.. - only really matters for chapter locations

[jsoto]

Hi,

I know 448k is the usual maximum rate in DD tracks included in DVDs and I'm not sure if a DD with a bitrate of 512k or 640k in DVDs is legit or not, but muxman accepts them

Because these bitrates have a frame size higher than the available room in one pack, there will be some packs without a frame header.
In my understanding, in these packs, muxman fails:
- Frame header count is filled to one. I believe it has to be zero.
- First access unit pointer is pointing out of the pack.

jsoto

PS: You can easily create a 512k/640k ac3 with besweet using a 384k as input:
BeSweet.exe -core( -input "Audio_384.ac3" -output "Audio_640.ac3" -logfile "Audio_640.log" ) -azid( -g 1 -c normal ) -ac3enc( -b 640 )

[mpucoder]

Or you could use silence. Anyway, 448 is the maximum allowed for DVD, so I'll add a check to reject these files. The reason for the max is probably related to pack size.

[jsoto]

TMPGEnc DVD Author and IFOEdit accept and mux the files, apparently ok. PowerDVD is able to play the produced DVDs.
I'd like to know what Scenarist does...
Or you could use silence. I forgot it!
jsoto

[mpucoder]

Scenarist accepted and muxed it. So I guess one book is wrong, and I'll be making a different change to Muxman.
One thing, though, could you send me a sample with audio to test playback? I don't do a lot of encoding, so can't make one myself without a big hassle. Silence may be golden, but it is no test of playback.

[jsoto]

Here they are:
www.videohelp.com/~jsoto/AudioTests/audios_ac3_highspeed.zip

I didn't test them in my 5.1 settop (I do not have 5.1 in my PC), because I encoded them just before go work. But they should work.

jsoto

[mpucoder]

Well, on my two Sony settops the 640Kbps is choppy, and at the same rate as the packs with no audio header occur (every 0.384 seconds, or 2.6Hz - sounds like the guy has phlem stuck in his throat). I couldn't hear anything unusual at 512Kbps, but then the headerless packs occur every 2.016 seconds. As expected PowerDVD and Nero Showtime have no problem.

The mux is identical to Scenarist, and passes the Philips Video Verifier (for what it's worth), so I am releasing a new version 0.13g available at the Muxman homepage (http://www.mpucoder.com/Muxman/)
But I cannot recommend using these bitrates as it appears not all settop players (or any?) play them properly.

[jsoto]

Yes, they are not used bitates, I've never seen these bitrates in a DVD.

For your info, I've tested Muxman output in my settop(Thompson) + 5.1 (Phillips) and it works fine at 640k. So, at least one settop works.

Just for the record, Muxman output is slightly different versus TMPG DVD Author and IFOedit authoring. The last both produce a pack with PTS=0 in the packs without Frame header. Muxman outputs the PTS of the next Frame header, so there are two audio packs with the same PTS

jsoto

[mpucoder]

Originally posted by jsoto
Just for the record, Muxman output is slightly different versus TMPG DVD Author and IFOedit authoring. The last both produce a pack with PTS=0 in the packs without Frame header. Muxman outputs the PTS of the next Frame header, so there are two audio packs with the same PTS
Are those actual PTS's of zero or the absense of a pts value? Vobedit show both the same way in the left pane, but the right pane will show a pes length of 0 or 5 and (if 5) the value.

My first attempt produced no pts field in the header (prior logic: no audio header = no pts) and Philips objected to it with error 3235, "pes packet payload for AC3 shall not exceed 2020 bytes". (without the pts field the payload is 2021 bytes)
So I looked at how Scenarist did it, which was simple to implement since the next pts value is always known - just don't suppress the field.

Just now I modified Muxman to make a pts of zero if there are no audio headers and the player froze at each packet, although Philips found no error.

[jsoto]

I didn't test in my settop+5.1 system the output produced by TMPG DVD Author or IFOEdit (the one with PTS=0), but I'll do and I'll let you know.
But probably not today, I have to work this night :(
jsoto

[SeeMoreDigital]

I could play the 512K file fine. But the 640K file was a bust... in a Pioneer DV-575A, Philips DVD711, LG FFH-DV25 and Sigma Xcard


Cheers

[SeeMoreDigital]

Sorry but I have to ask... Is it Muxman (as stated in the thread header) or MuxMan (as stated in the GUI)?


Cheers

[mpucoder]

Doesn't really matter, although I should be consistent. It started as MuxMan in DevStudio, which is not easy to change. But then the webpage is Muxman, on case sensitive Linux servers. Yes, I have speling (sic) enabled, but it adds overhead for every correction. (for those who don't administer Apache servers, speling intercepts 404 errors (page not found) and searches for a page with similar spelling, starting with case insensitive. The filter name is intentionally mispelled)

Maybe a poll to decide? It was only a working title to begin with, until I thought of a better name - which has not happened yet.

edit: I just noticed that the zip files are muxman, totally lower case.

[mpucoder]

While trying a few things to maybe eliminate the chopping of 640Kbps AC3 I decided to run the Philips Video Verifier again on my output. jsoto's sample is just the right length to not have a header on the second to last pack. As a result, there is no pts, and the verifier complained. It took a lot of code to fix that one little thing which I don't think will bother anyone. So the fix will be in MuxMan 0.14

But here's the interesting part. I ran the verifier on Scenarist's output as I think having a pts on the last partial pack is incorrect. The differences between Scenarist and MuxMan surprised even me. This is using the same audio and bmp for what Scenarist calls a "slideshow"
Scenarist (http://www.mpucoder.com/Muxman/Scenarist_h640_vob.txt)
MuxMan (http://www.mpucoder.com/Muxman/MuxMan_h640_vob.txt)

(yes, my name is John Bigboote :D NOT it is a reference to my favorite cult classic (http://www.imdb.com/title/tt0086856/) )

Geez, encoder errors and lots of synci errors. Maybe this is why Ralph LaBarge thinks many DVD players are incapable of playing slideshow w/audio?

[Zeul]

just shows that muxman is king :D

[cmsoliveira]

Hi,

just one simple question...

Can i use an mxp file to add more than 8 subs? Or will muxman use only 8?

Thnx

[mpucoder]

mxp files still limit subs to 8 until version 0.14

[cmsoliveira]

mxp files still limit subs to 8 until version 0.14

:(

Hope it come out soon.

Great job,BTW.

[jsoto]

I've double checked in the settops I own, and everything works fine using 640 k ac3 samples.

- Internal downmix to stereo.
Works fine with both samples (Muxman and TMPG DVD Author).
Works fine in both settops

- Raw digital (coax) output, connected to a 5.1 Phillips amplifier
Works fine in both settops, both samples (Muxman and TMPG DVD Author)

Settops:
THOMPSON DTH5200
AIRIS 103C

jsoto
Now, going to work....

[mpucoder]

I was just hoping for something to make my settops work. That happens frequently that a minor error is ignored by some players and not others.

btw - I updated the verifier listing for Scenarist when I realized I had made a default 10 second slide, not the full 59:20 (NTSC) of the audio.

[Sir Didymus]

Originally posted by mpucoder
Scenarist accepted and muxed it. So I guess one book is wrong, and I'll be making a different change to Muxman...


Well, first of all it's a pleasure to see that the authoring quality of MuxMan is better than the one of Scenarist. :)

For the quoted part (sorry if it's trivial what I say), IMHO it's very hard to believe books are wrong on such an important parameter like the maximum datarate of an ac3 audio stream. Much more realistic to think that even a blasoned authoring application like Scenarist may have bugs in it.

Maybe it's not even a matter of bugs, since when using 512K or 640K ac3 audio, we are outside of the DVD specs, so what an authoring application should do with this type of sources is questionable...

Even the most direct solution may be to properly detect and reject these streams, since them could not eventually being properly handled by all stl players, another approach may be to try to mux them in the best possible manner...

[Paulcat]

I was doing a dvd last week with MuxMan. and it gave me an error telling me I had a maximum GOP size of 40, and the resulting dvd would be out of spec. Granted, you could get MuxMan to check all the streams prior to muxing to ensure all are compliant, but where do you stop? If MuxMan assumes all streams are compliant at the outset, it should just mux the whole mess regardless of what the result is, in or out of spec. My dvd plays just fine thanks, although I don't know why I got a GOP of 40, I was using TMPGEnc and it was set for the correct value...

[mpucoder]

It's only a warning, and the value is fields. Yes, MuxMan could scan every asset beforehand, and be just as slow as Scenarist :)
But MuxMan does make every attempt to multiplex the files, even if they are out of spec. It will stop only when it is impossible to go on.

[SeeMoreDigital]

Hi mpucoder,

After using MuxMan beta 0.13g to mux the 640K AC3 audio stream, I can confirm I am now able to play them perfectly via, Pioneer DV-575A, Philips DVD711 and LG FFH-DV25

Strangely, my Sigma Xcard will not play the 640K stream after it's been "muxed", but it will play it as an .AC3 stream!


Cheers

[Paulcat]

Originally posted by mpucoder
It's only a warning, and the value is fields. Yes, MuxMan could scan every asset beforehand, and be just as slow as Scenarist :)
But MuxMan does make every attempt to multiplex the files, even if they are out of spec. It will stop only when it is impossible to go on.
That's what I assumed. After all, you should have some basic idea about your streams if you can get to the point of using MuxMan! It is odd though that the players are capable of playing out of spec material, although I wonder if the higher bitrate ac3 file sounds any better to the human ear than the in spec one...

[mpucoder]

In another part of the forum (Other MPEG 1/2 Encoders) there was a discussion about long gop's. They don't bother most players, afterall it's just 8 bytes in the bitstream saying what time it is. To a decoder that's just skipped info. And I have no idea why the restriction is there.

The high-bitrate sample I got was made from a lower bitrate, so it cannot possibly sound any better. But considering that I can tell the difference between 384K AC3 and its original PCM, it is likely that I could hear a difference. The principal difference is the definition. It's similar to listening to something on JVC and then on Bose. (or MTX and then anything else, even Peavey)

[Paulcat]

The only thing that sounds good on a JVC is a steamroller, and even then only briefly..