MuxMan 0.14 with navigation and highlights available

[mpucoder]

Very strange, as there were no changes made to the mux engine between those two releases. The message comes from the backfill operation, and means there was no NAV pack where it expected one. For me to debug it I will need a profile of the source files. If you still have 0.11c run it with "make profile?" checked and send me the file (c:\muxman.mxl) If you don't have 0.11c you can still download it from here (http://www.mpucoder.com/Muxman/muxman_0_11c.zip)

[nnigam]

Originally posted by mpucoder
OK, I missed that part since the main part of the post was about MuxMan disappearing.
sup files contain the actual graphics, so the place to change them, in your case, would be dvsuptools. Is there something about the originals you don't like? You can extract .sup files from a DVD using PGCDemux, and they will appear exactly as they did on the original.

Problem solved. Last time I used a tool called subtosup. I could not find it this time, and so used dvdsuptools. This has an ini file where options can be configured. Default was set to PAL, so the captions appeared at the bottom of the screen thinking it was a pal video.

Thanks for a very great tool

[manono]

Hi-

For me to debug it I will need a profile of the source files.

I'm sorry mpucoder, but everything's gone now. I've reinstalled 0.14f and I'll get the information you need if it ever happens again.

[Samyucca]

MuxMan version 0.14f

Congratulations on a great program. Does exactly what is needed to create DVDs with audio taken from radio broadcasts. Like the facility to use a bmp file instead of m2v.

However, I have had several problems with buffer underflows (that bring the the compilation to a halt) and chapter creation.
Example appended to Part 2 of this post: Log file says that 40 chapters were created, but only 22 chapters actually get created on the DVD. Log file see Part 2 of this post.

Audio files themselves must be OK, because eventually I got it to work by using vers. 0.13h plus restart plus editing the chapters text file plus reducing the number of bmps. Took a while though and I don't figure exactly what fixed it. Any do's and don'ts
a) in terms of number of bmps that can be used?
b) to avoid the "P-STD buffer underflow" I always seem to get - DVD is perfectly playable but if more than 5 "P-STD buffer underflows" occur the complilation process seems to halt?

[Samyucca]

Here is the log file referred to in my previous post "Chapters and BMPs in MuxMan", IFO files on request.
Sam

[mpucoder]

Need to see the mxp file as well.

[Samyucca]

Here is the mxp muxman_atlastsuccess_but only22chapters_insteadof40_rimini2.mxp.txt
that corresponds to muxman_atlastsuccess_but only22chapters_insteadof40.txt (the log file).

Seems the pgcs don't correspond to the scenes.

One additional question:

Is it wise not to load the same file twice (audio, e.g. five seconds silence between tracks, or bmp), are there any file locking issues?

Thanks

[mpucoder]

That's what I expected. You cannot create a chapter in the middle of a still, there's no video at the start of the chapter. This leads to the buffer underrun diagnostic, although not a true underrun. It is also why you cannot easily line the chapters up, but keep getting them placed somewhere else. In order to do this you must have at least one bmp for each chapter, and the durations must line up exactly with the chapter points.
This is so common that the next release will have a check for it, and stop if there is no video to start a chapter.
Making audio DVDs is also very handy, but very touchy. So I think this will be the first "wizard" I write for Muxman.
As for re-using files - it should not be a problem. Each file is closed before the next one is opened.

[Samyucca]

Thanks to mpucoder for the info.
You write "you cannot create a chapter in the middle of a still, there's no video at the start of the chapter" - well, I have done several DVDs with Muxman with as many as 66 chapters with no bmp alignment, so it seems to work quite often. With programs like DVDLab Pro you can create chapters within audio-only titles without having explicitly to load a still like bmp or jpg for each chapter. I'd prefer to work with Muxman though if possible.

How about including a function "automatically align chapters with bmps" or vice versa?
If one has to do it manually, if you have three chapters at 0, 10 min and 20 min, does each bmp need to have a duration of exactly 10 mins?
Some kind of multiple file selection for the bmps would be great too, or drag and drop from the Windows Explorer. Selecting 66 bmps one by one for 66 chapters is time-consuming.
Anyway, great program.

[mpucoder]

I'm not familiar with DVD Lab Pro, but I can tell you that according to the specs, there is no such thing as an "audio only title". There must be video at the beginning of every cell in order to be in spec. Now, I realize a lot of DVD players will forgive that, and continue to display the last frame, but it's not correct. Perhaps DVDLab Pro is adding its own still frame, or repeating the previous.

As I mentioned, I plan to write a wizard for this kind of use that will align the bitmaps and chapters with the audio.

As for selecting files, you do know that you can select more than one file at a time with the file open dialog in MuxMan. As usual, though, in Windows (be it multiple files from the open dialog or drag and drop) the order gets screwed up.

[DMagic1]

Any reason why Muxman wont accept a m2v created with Procoder?
Two movies created with DVDRB, one with CCE the other with Procoder. Demux both movies, the cce version accepted but not the Procoder version. I ran into this problem awhile back with another project.

[mpucoder]

What does the log (c:\muxman.log) say?

[SeeMoreDigital]

Hi mpucoder,

As you may already know Neuron2 has added Mpeg1 de-muxing to DGMPGDec 1.3.1 beta 9 (http://forum.doom9.org/showthread.php?p=663489#post663489). However, try as I might I'm still unable to use MuxMan to re-mux the streams back to .VOB :(

I keep getting GOP length error warnings!

http://img113.echo.cx/img113/1629/muxman8ew.png

Is Mpeg1 muxing possible yet?


Cheers

[mpucoder]

Mpeg-1 has always been possible. But the same GOP constraints apply. This is not a Muxman restriction, but DVD. And considering that mpeg-1 has only frame pictures, more than 36 pictures means morethan 36 frames - twice the limit for DVD.
Make sure gop headers are not being removed - look at the original DVD with VobEdit to see how often [gop] occurs in the left pane. It should happen every I frame.

[laserfan]

mpucoder I want to thank you for this great tool. I had a mux job to perform which which crashed IfoEdit, then resulted in timestamp problems and playback jerkiness when I tried ReJig, but finally I found MuxMan and I have a smooth-as-silk Title Set now.

I did have one nasty problem (wish I'd seen this thread & had known where the logfile was!) where towards the end of the mux, I got an error and the mux process just stopped-dead & aborted with: "Multiplex operation halted ! Reference to non-existant scene segment_1_scn26 from PGC". Had no clue what this might be, and fretted a bit that my re-worked subtitle .sup was at issue (my reason for de-mux/re-mux) but on a hunch I compared the DVD chapter markers with the celltimes.txt I'd gotten out of IfoEdit. I had 25 entries in celltimes.txt and only 24 actual chapters, the 25th chapter-advance going to the Main Menu. So I deleted the last two lines of celltimes.txt and ran it again. Success!

I dunno why IfoEdit "lied" about chapters (not one, but TWO extra??), but you may want to look at incorporating a more graceful exit strategy for encountering this problem if possible. Thanks again for this terrific program!

EDIT: Now I've gone to Page 1 to read this entire thread and see this has been reported... :rolleyes:

[SeeMoreDigital]

Thanks mpucoder,

I've probably have asked this before, but does anybody know of any tools/applications that can alter the GOP structure of Mpeg2 (and Mpeg1) streams. So they are suitable for muxing into DVD compliant .VOB files?


Cheers

[DMagic1]

What does the log (c:\muxman.log) say?


MuxMan version 0.14f
Rejected sp r/fr F:\MOVIE\D2VAVS\V07000000001001.m2v

[sweetness]

I've probably have asked this before, but does anybody know of any tools/applications that can alter the GOP structure of Mpeg2 (and Mpeg1) streams. So they are suitable for muxing into DVD compliant .VOB files?

ReStream (http://shh.sysh.de/restream.html)?
Don't know if this can help you.

[mpucoder]

OK, in the readme file is an explanation of the rejection codes

Rejection codes:
OERR Muxman was unable to open the file.
BERR Muxman was unable to allocate resources to the file (low memory).
sp r/fr non-spec resolution / framerate combination.
sp ar non-spec aspect ratio (must be 4:3 or 16:9)
nm enc non-matching coding mode (mpeg-1 or mpeg-2)
nm std non-matching tv standard (NTSC or PAL)
nm res non-matching resolution
nm ar non-matching aspect ratio
nm p/s non-matching pan/scan capability
nm cc non-matching closed captioning


sp means a spec violation, and r/fr means resolution and/or framerate. Most likely pulldown was applied, but the framerate not changed accordingly to 29.97 You can use ReStream or DVDPatcher to see the resolution and framerate in the file headers.

[SeeMoreDigital]

ReStream (http://shh.sysh.de/restream.html)?
Don't know if this can help you.I've had a look at ReStream (which seems to work with some Mpeg1 .m1v streams too) but I can't find any "How to" information with regard to changing GOP's.

On a related note... I've received some e-mails from people in the UK who would like to use MuxMan to transfer their DVB-S and DVB-T Mpeg2 captures to DVD VOB, but can't due to the weird GOP lengths DVB uses.

So far the only solution seems to be re-encoding the entire Mpeg2 stream, but surely there's got to be another way?

I would really like some advice on how to address this problem so I can pass the information on to others, so we can all use MuxMan.


Cheers

[mpucoder]

A gop must start with an I frame, so if there are not enough I frames to make shorter gop's then the video must be re-encoded.
There is a reason for the gop length restriction, and it has nothing to do with picture quality (arithmetic error accummulation) or any decoder related issues. The gop length restriction sets the maximum size of the most basic unit used to compose a VOBU. And VOBU's in turn have length restrictions as well of 0.4 to 1.0 second except the last of a cell, which may be as long as 1.2 second. Having gop's longer than 0.6 seconds (the difference between the shortest and longest allowable VOBU) would create situations where it is impossible to compose a compliant VOBU.
And a gop longer than 36 frames is either 1.2 or 1.44 seconds long, depending on television standard, which is longer than a legitimate VOBU.
If DVB streams are not DVD compliant then they can't simply be stuffed into a vob to be played on a DVD player, they must be processed before authoring.

[goonix]

The program womble mpeg2vcr (for cutting and combining mpeg2 files) has a tool called gopfixer. It divides a too long gop in two shorter ones with a new i-frame in the second part. Only this gop needs to be reencoded.

Since not all gops of a DVB-S or DVB-t stream are too long, but only a view of them, the whole movie is fixed in a view minutes. Then it will be accepted by muxman.

goonix

[Trahald]

MuxMan version 0.14f
Rejected sp r/fr F:\MOVIE\D2VAVS\V07000000001001.m2v

dvd rb probably fixes the framerate when it muxes (its assets are created with the intention of being remuxed by itself)

[DMagic1]

thanks

[Koepi]

I ran into trouble, too - muxman.14 tells me that it rejects to mux my files because of a invalid palette entry. Using muxman.8 it works flawless. [But it overwrote the logfile, have to redo that later and add the log.]

I didn't read the whole thread now and hope that this issue isn't already covered ;)

Cheers
Koepi

[ffreese]

Hi,

muxman 0.14f does not accept any audio delay > 300 ms.

is it a bug or a feature?

is there any quick and dirty program that can correct the audio-data itself by >300ms?

[SeeMoreDigital]

The program womble mpeg2vcr (for cutting and combining mpeg2 files) has a tool called gopfixer. It divides a too long gop in two shorter ones with a new i-frame in the second part. Only this gop needs to be reencoded.

Since not all gops of a DVB-S or DVB-t stream are too long, but only a view of them, the whole movie is fixed in a view minutes. Then it will be accepted by muxman.Thanks goonix,

I've just run a few short files thru' Womble's MPEG-VCR (http://www.womble.com/products/). It's "MPEG Video GOP Fixer" tool managed to correct every DVB Mpeg2 stream, which previously MuxMan did not like. But it was unable to help with any of my Mpeg1 streams :(

I know I can be a bit (well very) dumb at times... but can anybody confirm whether they have successfully muxed PAL 352x288 Mpeg1 streams into .VOB with MuxMan?

And my apologies to mpucoder if this question upsets/annoys him!


Cheers

[Trahald]

@SeeMoreDigital
Try creating a compliant mpeg1 stream ( cce is very good at sticking to gop restrictions m = 3 & n/m = 5 for pal) and run it against mux man. that will provide the test needed.

gop longer than .6 seconds will result in non-compliant stream (verifiable in 5 mins with google). now there are dvd authoring programs that will accept it.. but its still not compliant. Most Pro level apps (like scenarist) will reject such files.

[SeeMoreDigital]

Thanks Trahald,

I don't have CCE installed :(

However, do you think a DVD compliant Mpeg1 output can be generated by altering TMPGEnc's GOP settings?

http://img300.echo.cx/img300/1703/gopsettings8li.png


Cheers

[nnigam]

You should be able to use avisynth for this. For dvd, the stream has to be 720x480 @29.97 fps for NTSC or 720x576 @25fps for PAL. Avisynth, and dgpulldown should work very well for this. But I do not work too much with mpeg1. I just convert my hd captures to dvd without any problem as long as long as the video has these resolutions and frame rate.

[Trahald]

some encoders overshoot the values. you should be able to use tmpgenc.. you could set the p-frames to 3 to give it a little room to play with( i = 1 b = 2 p = 4 is equivelant to 15 frame gop). and 352x288 is acceptable pal resolution

[mpucoder]

Sequence header for every gop
max frames per gop = 18

[SeeMoreDigital]

Thanks guys I'll give it a go and report back.

Sorry for taking up so much thread space discussing this (probably pointless) matter!


Cheers

[Matthew]

I believe sst subtitles are broken again. The colors/mapping is all wrong when using ssts produced from vsconv.exe on a sub/idx, + the default palette. The version I had been using for a while was just fine but now 0.14f is buggering up.

The problem occurred with 2 sets of ssts.

[AndyP]

Hi

Attempting to recompile backup of Without A Paddle (R2) - using DVD Decrypter 3.5.4.0, Scenaid 1.6, BatchCCEWS 0.9.1.5 and Muxman 0.15RC1.

Attempting to load Scenaid script results in the following error.

'Errors encountered in project file. See log file for details'

Last lines of log


Accepted still C:\Program Files\ScenAid\dummy_PAL_43.M2V size = 9188
Accepted still C:\Program Files\ScenAid\dummy_PAL_43.M2V size = 9188
Accepted still C:\Program Files\ScenAid\dummy_PAL_43.M2V size = 9188
Accepted still C:\Program Files\ScenAid\dummy_PAL_43.M2V size = 9188
Accepted still C:\Program Files\ScenAid\dummy_PAL_43.M2V size = 9188
Accepted still C:\Program Files\ScenAid\dummy_PAL_43.M2V size = 9188
Accepted still C:\Program Files\ScenAid\dummy_PAL_43.M2V size = 9188
Accepted still C:\Program Files\ScenAid\dummy_PAL_43.M2V size = 9188
Accepted still C:\Program Files\ScenAid\dummy_PAL_43.M2V size = 9188
Accepted still C:\Program Files\ScenAid\dummy_PAL_43.M2V size = 9188
Accepted still C:\Program Files\ScenAid\dummy_PAL_43.M2V size = 9188
Accepted still C:\Program Files\ScenAid\dummy_NTSC_43.M2V size = 8276
expanded database to 33000 entries.
Cell name VTS3_Title1_PGC1_PG1_C2_cellblock is too long
Cell name VTS3_Title1_PGC1_PG2_C3_cellblock is too long
Cell name VTS3_Title1_PGC1_PG4_C2_cellblock is too long
Cell name VTS3_Title1_PGC1_PG5_C2_cellblock is too long
Cell name VTS3_Title1_PGC1_PG6_C1_cellblock is too long
Cell name VTS3_Title1_PGC1_PG7_C3_cellblock is too long
Cell name VTS3_Title1_PGC1_PG9_C2_cellblock is too long
Cell name VTS3_Title1_PGC1_PG10_C2_cellblock is too long
Cell name VTS3_Title1_PGC1_PG11_C1_cellblock is too long
Cell name VTS3_Title1_PGC1_PG13_C2_cellblock is too long
expanded database to 33100 entries.
Cell name VTS3_Title1_PGC1_PG13_C5_cellblock is too long
Cell name VTS3_Title1_PGC1_PG14_C1_cellblock is too long
expanded database to 33200 entries.
expanded database to 33300 entries.
expanded database to 33400 entries.


Complete log and SCP - http://www.somewhere-out-there.eclipse.co.uk/WOAP - Muxman.rar

Regards,
Andy

[jel]

is it just me, or is this a little odd?Accepted still C:\Program Files\ScenAid\dummy_NTSC_43.M2V size = 8276 and from the .scp: Item=Encoded Still
{
Place Holder=No
Name=dummy_VTS_Data
Resolution=PAL
Drop Type=Non-drop Frame
Data Start Time=00:00:00;00
Data End Time=00:00:09;29
File=C:\Program Files\ScenAid\dummy_NTSC_43.M2V
Width=720
Height=576
Is Encoded=Yes
Encode Type=MPEG 2
Size=720 x 576
Aspect Ratio=4 : 3
Picture Structure=Frame Structure
GOP Size=15 frames
GOP Structure=N/A
Bit rate=9800000
Average Bitrate=6000000
Minimum Bitrate=4000000
} try changing the asset its pointing to, to "File=C:\Program Files\ScenAid\dummy_PAL_43.M2V" and modify the .scp.

dont know if that will help mind you ..... ;)
just an un-educated guess.

[AndyP]

Still fails. The error seems to be in VTS 3 looking at the muxman log.

Regards,
Andy

[mpucoder]

The error is about the number of characters in the symbolic names. They are limited to 31 characters. Scenaid was changed to accomodate this, but I'm not sure at what version, and whether it was .mxp only or both scripting languages. I'll ask d3s7.

[D3s7]

It is somewhat fixed in the unreleased build however, if you have "cellblocks" in your script then you have a movie with angles...

Muxman currently can't handle angles (at least I don't believe so) so i'm not really sure what it would do even if the script was understandable

[AndyP]

Thank you both. I shall wait patiently for a ScenAid that does short names and a Muxman that does angles! :)

Regards,
Andy

[Matthew]

This sounds like a nag, but mpucoder, any comment on my post above? Thanks :)

[D3s7]

I believe sst subtitles are broken again. The colors/mapping is all wrong when using ssts produced from vsconv.exe on a sub/idx, + the default palette. The version I had been using for a while was just fine but now 0.14f is buggering up.

The problem occurred with 2 sets of ssts.

Default palette is the scenarist default palette, not one based off the VTS, i would imagine it would be incorrect.. if your going to use the defaultpalette options, make sure not to copy over the subtitle info during the ifo update step

[Matthew]

Default palette is the scenarist default palette, not one based off the VTS, i would imagine it would be incorrect.. if your going to use the defaultpalette options, make sure not to copy over the subtitle info during the ifo update step

Thanks for the reply.

I'm not using IFOUpdate or any other IFO editor as this is not for a full backup (yes, I know I'm going to hell). It's just a straight audio+video+subs in MuxMan (both GUI and cli), followed by a viewing in PowerDVD.

The subs look fine in Scenarist, and they did in a previous version of MuxMan too (after mpucoder fixed not dissimilar issues).

I'm a cheapskate so I don't have 0.15, but I presume it is okay in this regard...

[mpucoder]

There have been no changes in the default palette colors, or the way in which they are defined.
There were, however, corrections to .sst interprettor. These were for MaestroSBT, though. And vsconv may have been changed as there were many discussions with various authors about the correct syntax of the .sst file.
If you could post a section of one of your .sst files, everything before the actual list of bitmaps, I could tell more.

[Matthew]

The version of vsconv I use has not changed (if I recall correctly it's the last one by gabest[1.0.0.5]...before any alterations by the big x crew). I have a 'system' into which I dropped the new version of muxman and the only other change I had to make was how the mxp was generated (inclusion of the default palette and navigation).

The latest test I did using the GUI were from the first chapter subs of Minority Report (PAL). The subs (in sst format) have been on the HD for well over a year and I used them without problems in a previous version of Muxman. It's the third set of subs I've tried, too.

st_format 2
Display_Start non_forced
TV_Type PAL
Tape_Type NON_DROP
Pixel_Area (0 573)
Directory H:\minoritychap1\subs
Subtitle 00-
Display_Area (0 2 719 574)
Contrast (15 15 15 0)

PA (0 0 255 - - - )
E1 (255 0 0 - - - )
E2 (0 0 0 - - - )
BG (255 255 255 - - - )

SP_NUMBER START END FILE_NAME
Color (3 4 14 3)
Contrast (13 15 0 15)

Thanks :)

[mpucoder]

I ran tests using a test bitmap with fully saturated colors and found no difference in how MuxMan and Scenarist converted it to a subpicture. So I devised a new bitmap with half-saturated colors as well, and they were different.
So, a few of things:
1) the minus (-) sign is not a recognized conversion rule by Scenarist, it treats all unrecognized rules as &
2) because so many other programs had used minus instead of equal, and for pure colors & and = act the same, MuxMan treats - as =
3) MuxMan does not do & the same way as Scenarist

Meaning if the bitmap is pure white, black, red, and blue it will map the same as Scenarist. But if it is not, there is no way currently to map it the same as Scenarist.

MuxMan 0.15 will change the & operator to work the same as in Scenarist, and - will be treated as &

Now, having gone through all that, if the colors rendered on playback are not the same, make sure the default palette is correct. MuxMan uses the same default palette as Scenarist, and does not need it to be defined in .mxp If you want to see what that palette is, start MuxMan and immediately save the project.

[D3s7]

Matthew,

can we get a couple screen/window shots of right -vs- wrong...

I'm interested in this as well

also, are you positive your using the original vsconv and not one of mine..

[sweetness]

i need some help with sst file and muxman(.14f). for some reason it just doesn't want to mux the subs in.
i extracted a cell with Vobblanker ripped the subs with subrip1.3(edited the start and end times) and ripped the video and audio with pgcdemux. i tried muxing a bmp+audio+sst, nothing.
i tried muxing the m2v file from pgcdemux+audio+sst nothing again.
i don't get any file in the .mxp
Item=Sub-Picture Stream
{
Stream Number=1
Language Extension=1
Display Mode=unspecified
}
Item=Scene List
{
if i use subrip 1.17 i do get a file in the .mxp, but when i rerip the subs it's blank.
Item=Sub-Picture Stream
{
Stream Number=1
Language Extension=1
Display Mode=unspecified
Item=Sub-Picture Play
{
File=C:\aa.1.bmp
Start=00:00:00:00 (0)
Forced Start=No
Time Code=NTSC non-drop
Duration=00:00:34:27
Origin=0,0
Display Area=0,2,719,479
Color 1(Pa)=0000ff & & &
Color 2(E1)=000000 & & &
Color 3(E2)=ff0000 & & &
Color=4 3 2 1
Contr=0 0 0 0
}

any advice on what i'm doing?

[mpucoder]

See the note in readme.txt about SubRip 1.17

[sweetness]

look at the first pack (NAV) and find "vobu_s_ptm" - this is the number
to use for your rip.
do you mean the - vobu start presentation time (90KHz clk) 1827057?
this number is too high.