Muxman version 0.12 released

[mpucoder]

Available here (http://www.mpucoder.com/Muxman/)
New features:
full support for field pictures
8 subpicture tracks
import Muxman or Scenarist project files (scripts)
export Muxman project files
batch mode / command line processing

[katjarella]

Dear mpucoder,

unfortunately, something doesn't work with subtitles. The following error message appears:

Opened sub 1 file F:\temp\muxman\sourcen\TEMP\SUBs\Mai01-Mai04_TEST.sst.
Pixel_Area values 0 572 are incorrect, using default of 0 572.
Display_Area Y values 2 574 are incorrect, using default of 2 574.
F:\temp\muxman\sourcen\TEMP\SUBs\\Mai01-Mai04_0001.bmp adjusted start time is negative (SubRip delay too high). file skipped.

Here is my SubScript:

st_format 2
Display_Start non_forced
TV_Type PAL
Pixel_Area (0 572)
Display_Area (0 2 719 574)
PA (0 0 0 - - - )
E1 (255 0 0 - - - )
E2 (0 0 255 - - - )
BG (255 255 255 - - - )
SubTitle 0020
Directory F:\temp\muxman\sourcen\TEMP\SUBs\
#############################################################
SP_NUMBER START END FILE_NAME
#############################################################
Contrast (15 15 15 0)
Color (2 1 7 1)
0001 00:00:10:00 00:00:48:00 Mai01-Mai04_0001.bmp
Color (2 1 1 1)
0002 00:01:00:00 00:01:20:00 Mai01-Mai04_0002.bmp
Color (2 1 7 1)
0003 00:01:40:00 00:02:00:00 Mai01-Mai04_0003.bmp
Color (2 1 1 1)
0004 00:02:02:00 00:02:40:00 Mai01-Mai04_0004.bmp


Furthermore, I noticed the following issue: Until version 0.11, I was able to use the VOBs with dvdauthor, too; unfortunately, since version 0.12 this does not work anymore.

Thanks for v.12 ... Katjarella

[mpucoder]

NTSC subpictures are supposed to have an even number of lines, unfortunately the check doesn't care which tv system is used. It doesn't change the output, though. I have removed the check and replaced the zip file without a revision number change. Also the delay should be correct now.

All the tests run on Muxman (which are now automated thanks to project files) showed no changes in output. The exception, of course, is field pictures which were wrong before.

One thing about your sst script - the contrast line will be skipped. Any line following a line with all "#" will be skipped.

[mpucoder]

I was thinking more about the skipping line. Originally any unrecognized line, like the with SP_NUMBER in it would have caused a syntax error. But the parser now just ignores anything it does not recognize. So I will be changing the parser to treat a line of all "#" as just a single line comment.

There is one thing that should be corrected in your script, for both Muxman and Scenarist. And that is the conversion rules. These are the symbols that follow the color values, eg PA (0 0 0 - - - )
the - - - are the three conversion rules. The only characters Scenarist allows are < = > &, these define the relationship between the stated color and that in the bitmap. - has no meaning and will be replaced with & by Scenarist, meaning if the bitwise AND of bitmap color and value from the script is non-zero then that is a match.
Muxman right now does not process the rules in an sst file (it assumes = = =), so you get away with it. But that will change (I missed it this time), and you may be surprised at the subpictures.

[katjarella]

Ok, mpucoder...

The Original Scenarist Script:
***
Item=Video {
Place Holder=No
Name=TESTSTREAM
Resolution=PAL
Drop Type=Non-drop frame
Data Start Time=00:00:00;00
Data End Time=00:01:19;24
File=F:\temp\muxman\sourcen\TEMP\TESTSTREAM.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
Bitrate Type=Variable
Icon Time=00:00:00;00
Line21 Switch1=No
Line21 File1=
Line21 Switch2=No
Line21 File2=
}
***
Item=Sub-Picture {
Place Holder=No
Name=Mai01-Mai04_0001
Resolution=PAL
Drop Type=Non-drop frame
Data Start Time=00:00:00;00
Data End Time=00:00:10;00
File=F:\temp\muxman\sourcen\TEMP\SUBs\Mai01-Mai04_0001.bmp
Width=720
Height=576
Is Encoded=Yes
Screen Size=Size {
X=720
Y=576
}
}
***


and the Muxman Script:

***
Item=Segment {
Name=Segment_1
Display Mode=4:3
Item=Video Stream {
Coding Mode=Mpeg-2
Standard=PAL
CC Field 1=No
CC Field 2=No
Item=Video Play {
File=F:\temp\muxman\sourcen\TEMP\TESTSTREAM.m2v
Size=10024552
Duration=Actual
}
}


Item=Sub-Picture Stream {
Stream Number=1
Language=en
Language Extension=1
Display Mode=unspecified
Item=Sub-Picture Play {
File=F:\temp\muxman\sourcen\TEMP\SUBs\Mai01-Mai04_0001.bmp
Start=00:00:00:00 (0)
Forced Start=Yes
Time Code=PAL
Duration=00:00:10:00
Origin=0,0
Display Area=0,2,719,574
Color 1(Pa)=000000 & & &
Color 2(E1)=ff0000 & & &
Color 3(E2)=0000ff & & &
Color=2 1 7 1
Contr=15 15 15 0
}
}
***


and The Error: Sub stream 1 sst tv_type disagrees with video

But in Scenarist, the same SubScript works flawlessly.

[Matthew]

Fantastic to see project file/cli support. Although I think it's a huge shame that it's not possible to just specify an sst, instead of each individual subpicture and it's attributes. This would make auto generation of project files so much easier for people like me.

Also, in case you didn't know, the project file extention (mxp) seems to match that of the macromedia extension manager (which is installed with dreamweaver).

[mpucoder]

You can use an sst or sup file, it looks like this:

Item=Sub-Picture Stream
{
Stream Number=1
Language=en
Language Extension=1
Display Mode=Wide/Letter
File=D:\MuxSrc2\cu.sst
}


Maybe a different extension?

[mpucoder]

@katjarella - I think I fixed the tv standard problem. Any fixes after this will get a new revision.

[Matthew]

I take back what I said. Pure awesomage :D

Yes, maybe you should change the extension, only because dreamweaver is so popular. Perhaps mmp? You can input possibilities at http://filext.com and see if they are already taken by well-known apps :)

[mpucoder]

I'll check that out.
After you load a script with an sst it gets expanded, so saving the project will be in the format that lists each file.

[katjarella]

Originally posted by mpucoder
@katjarella - I think I fixed the tv standard problem. Any fixes after this will get a new revision.

Ok, Thanks... I wait in the MPUCoder's DVD Forum Index » Muxman Alpha // Download Center :)

[mpucoder]

The fix is online now. And any fixes will be public. It's just that from now on I will give them revision numbers (letters, actually). A new series of alpha's will start Monday.

I'll have some documentation online about the project file soon. There is one other not-so-obvious thing you can do. Scenarist does not allow more than one motion video file in a track (segment to Muxman), instead they use a "concatenation file list" in a file with the .cfx extension. Muxman will import and expand these.

[Matthew]

I tried 2 ssts via the GUI and the results were funky - the background was black instead of transparent for a start.

The ssts were saved from a sub/idx using SubResync/vsconv.exe. Here's one of them"

st_format 2
Display_Start non_forced
TV_Type NTSC
Tape_Type NON_DROP
Pixel_Area (0 477)
Directory .
Subtitle saved
Display_Area (0 2 719 479)
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 (9 4 15 3)
Contrast (15 15 0 15)
0001 00:01:39:02 00:01:41:25 saved_0001.bmp
0002 00:01:42:24 00:01:46:23 saved_0002.bmp
0003 00:01:47:16 00:01:49:15 saved_0003.bmp

[mpucoder]

I see contrast there twice, first with background transparent, second is opaque. All the statements before a bitmap entry replace the previous value(s).

[jsoto]

A BIG thanks. I'll give it a try in CLI mode..
jsoto

[Matthew]

Originally posted by mpucoder
I see contrast there twice, first with background transparent, second is opaque. All the statements before a bitmap entry replace the previous value(s).

Deleting the contrast line above the BMPs resolves the transparency issues but the colours are still wrong. I have little idea about the tech specs for ssts, but Scenarist does treat them properly.

[mpucoder]

You still have to put the colors into the PGC manually. sst files have no color information.

The next version will add a lot more to what a project file can do, including setting the CLUT, but just this version required 110 keyword/context combinations. This was to get it to the same level as the gui.

[Matthew]

Of course, forgot about the palette. Muxman's default palette differs from Scenarist's and presumably gabest produces ssts to fit the latter's default.

But that aside, I'm having issues with some other subs. The bmps on these are unusual, compared to the typical blue background, red text and white outline. They consist of a black backround and a small white box around the text area, and the text is red with a blue outline.

Scenarist handles these just fine using the inputted sst, Muxman doesn't, the background is white etc. It would appear Muxman detects what the background is differently from scenarist.

st_format 2
Display_Start non_forced
TV_Type NTSC
Tape_Type NON_DROP
Pixel_Area (0 477)
Directory H:\test\subs2
Subtitle test
Display_Area (0 2 719 479)
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 10 3 3)
Contrast (0 0 0 0)
0001 00:00:00:00 00:00:00:01 test_0001.bmp
Contrast (0 15 15 0)
0002 00:00:30:08 00:00:35:26 test_0002.bmp
0003 00:02:54:25 00:02:57:18 test_0003.bmp
Contrast (0 0 0 0)
0004 00:03:32:27 00:03:32:28 test_0004.bmp
Contrast (0 15 15 0)
0005 00:03:40:13 00:03:46:17 test_0005.bmp
0006 00:03:55:08 00:03:56:29 test_0006.bmp
0007 00:04:01:07 00:04:04:20 test_0007.bmp
0008 00:04:17:08 00:04:18:17 test_0008.bmp
0009 00:04:23:17 00:04:25:25 test_0009.bmp
0010 00:04:49:19 00:04:51:16 test_0010.bmp
0011 00:04:51:22 00:04:53:06 test_0011.bmp

[mpucoder]

Re-read your post. Could you send one of the bitmaps to me - muxman (at) mpucoder (dot) com

Muxman actually has no rule for the background - if a pixel is not P, E1, or E2 it is BG. What else to do with a pixel that matches nothing?

[Matthew]

I've sent you the sample. It's a good testing set because of all the subtitles I've saved using the vobsub tools I've never seen the bmps come out like that.

[mpucoder]

I'll run them through Scenarist to compare. One thing though, the minus sign does get interpretted by Scenarist as "and". Right now Muxman does not interpret the rules, and treats everything as "=". Still, I think the colors will match by that rule. btw, I think I recognize the movie (Die Another Day).

[Matthew]

Yes it is Die Another Day. Given the way the franchise is going it's a shame Bond lived to die another day.

Anyway, in regard to another issue, I tried specifying only the sst in the project file. Opening it in the gui and compiling is file, but when -run is used at the commandline, subtitles are ignored. I take it this is due to the project file being 'expanded' when it is loaded via the GUI, but not when it is executed in batch mode. Is it possible to change this? :)

[mpucoder]

I just found some horrible bugs in sst processing - and my apologies to Matthew and Katjarella for having to try to use the buggy version. I do test, but in this case a new reference had to be made after the mods for field pictures were put in (they change timing). Apparently the bugs were there when the reference was made. It's fixed now, and I was just about to release the fixes when I read this, so hang on.

[mpucoder]

I see what happened. The subpictures are there, but not in the ifo file. The function that sets that up isn't called because it's not designed to work without a window (it sets up all the controls in the subpicture area).

edit: it is fixed now and available at the Muxman homepage (http://www.mpucoder.com/Muxman/)

[Matthew]

It is only version 0.12 and in heavy development, users experiencing bugs goes with the territory.

I've tried 0.12a with two ssts in cli mode and the results seem just fine. Now it's time to give mplex/spumux/DVDAuthor the boot :)

[mpucoder]

Thanks for the feedback - time to rest for now.

[Orion|69]

First of all : i truly love what u accomplished sofar with muxman.. i really believe it muxes better than Scenarist even, altho others dont agree with me on that :)

What i was wondering tho.. did u run into some limitations for the number of subtracks ? Normally 8 would be enough ofcourse, but alot of older PAL classics often have 20+ tracks and the max according to the DVD standards is 32, so thats why i wonder why not go for max 32 at once, unless, ofcourse, u ran into a limitation.

Keep up the great work tho :) I'd love to ditch Scenarist completely one day and go for MPUCoder's Multiplexing Engine (altho i doubt that will be just as free as muxman is hehe).

[dragongodz]

What i was wondering tho.. did u run into some limitations for the number of subtracks ?
to quote mpucoder

Muxman internally can process all 32 subpicture streams, it is only the GUI that is limited. The problem is what you're seeing now will become the demo for the full featured product, and I have promised never to take anything away from it. So I have to restrict it in some places.
which was actually in response to Muxman being limited to 3 subs at the time.

[SeeMoreDigital]

Thanks mpucoder,

Still loving it... Great work indeed :D


Cheers

[Orion|69]

My bad :)

They should install the mod so u can search in the thread itself :)

[mpucoder]

It's nice to wake up to no problems.

I forgot to mention this in the first post, but the modifications to make field pictures work also raised the GOP limit to 36 pictures (frame or field, doesn't matter) and the check is no longer based on tv system. So those of you who previously had problems with DVB sources should be able to mux without re-encoding. If you are concerned about DVD spec, the minimum and maximum number of fields per GOP is reported in the log and final dialog box.

[buzzqw]

Wow ! Great release !

just a question: could be possible (or not) in a near future to support sub/idx or srt subtitles ?

Thanks

BHH

[mpucoder]

I do plan to support some form of text subs in the future.

break:

For those of you interested, the docs for mxp files are now available here (http://www.mpucoder.com/Muxman/mxp/content.html)

[Zeul]

This is becoming VERY interesting. I would love to be able to ditch Scenarist (or at least give an alternative) and i have thought for a while that muxman is the way forward. How advanced is the scp parsing going to be? Will BOV (needed for menus of course :)) be implemented from a scp file? At the moment my initial thought was to run muxman for every vobid then parse the 'new' ifos and then create a new one. I welcome your thoughts as always.

Zeul

edit: should have read your previous post and checked out the link. Looks like it all will be eventually :)

[SeeMoreDigital]

I've just made an observation which, because of my limited understanding of DVD files, I'm not sure whether it's relevant or not!

Anyway, while using my trusty Sigma Xcard to play a couple of PAL 4:3 muxes, I noticed that if I navigate and launch playback by selecting either the VTS_01_0.IFO and VTS_01_1.VOB files, the video is displayed at the correct aspect ration (ie: 4:3) on my 16:9 TV.

But if I navigate and launch playback by selecting the VIDEO_TS.IFO file, the video is displayed at 16:9 and appears to loose the 4:3 signalling code!

I hope I've been able to explain this correctly?


Cheers

[mpucoder]

Originally posted by Zeul
How advanced is the scp parsing going to be? Will BOV (needed for menus of course :)) be implemented from a scp file?
Yes, highlight information will be parsed from scp/mxp files. I stopped at this point to release 0.12 as the parsing covered all the functionality of the gui. The next step is to turn the simple single-segment lists of files into a multi-dimensional database. Then the parsing development can proceed.
I, too, am looking forward to the day when Muxman can build menues and multiple titles.

[mpucoder]

The menu in VIDEO_TS.VOB, which actually has no video, is set to 4:3. But that is quite common for DVD's, and the reason why there are seperate flags for the vmg (VIDEO_TS), vtsm (VTS_01_0) and title. There should be no problem starting with either .ifo file, but starting with a vob file can quite often get you the wrong AR as the mpeg-2 DAR does not have to match the ifo DAR.

[katjarella]

Thank you very much for that fix, mpucoder, the first tests look great. But I have to run further tests.

I found the reason for problems with dvdauthor and the newest version:

Sourcen: motion_blend.m2v
Num. of picture: 20
Resolution: 720*576
Aspect ratio: 16:9 Generic
Framerate: 25.00
Nom. bitrate: 9800000 Bit/Sec
VBV buffer size: 112
Gop no.,Timecode,Pic n.,Pictures,Closed,Broken l.,Has SeqHdr,Offset
1,01:00:00.00,10,IPPBPBPBPB,Yes,No,Yes,00000be
2,01:00:00.10,10,IBPBPBPBPB,No,No,Yes,00317ef
TEST001.bmp
720x576Pix
AUDIO1.ac3 & AUDIO2.ac3
Total frames: 4.999
Frame size: 512 bytes
Sample rate: 48.000 Hz
Data rate: 128 kbps
------------------------------------------
Standard Multiplex: Video POS1: motion_blend.m2v = actual
Video POS2: TEST001.bmp = audio end
Audio1 = AUDIO1.ac3
Audio2 = AUDIO2.ac3
ReMultiplex with dvdauthor: MuxMan011c & MuxMan012a = No Problem
------------------------------------------
NON Standard Multiplex (my whish): Video POS1: motion_blend.m2v = 00:00:40:00 *
Video POS2: TEST001.bmp = audio end
Audio1 = AUDIO1.ac3
Audio2 = AUDIO2.ac3
* MuxMan011c + unhide the Duration Edit* :)
* MuxMan012a via script Duration=00:00:40:00

ReMultiplex mit dvdauthor: MuxMan011c = No Problem
ReMultiplex mit dvdauthor: MuxMan012a = ErrorSTAT: Processing MuxMan012a.vob...
assertion "j>=s->vi[i-1].sectpts[1]" failed: file "src/dvdvob.c", line 1234
6 [sig] dvdauthor 2072 open_stackdumpfile: Dumping stack trace to dvdauthor.exe.stackdump------------------------------------------

Please, please, change that back. I don't like the mix of motion and
stills, because the transitions become visible, unfortunately.

[mpucoder]

Check your PM, there is an experimental build to see if alternate_scan vs zig_zag is the problem.

[SeeMoreDigital]

Originally posted by mpucoder
The menu in VIDEO_TS.VOB, which actually has no video, is set to 4:3. But that is quite common for DVD's, and the reason why there are seperate flags for the vmg (VIDEO_TS), vtsm (VTS_01_0) and title. Why then, if the VIDEO_TS.VOB is set to 4:3, does the file play back at 16:9?


Cheers

[mpucoder]

Originally posted by SeeMoreDigital
Why then, if the VIDEO_TS.VOB is set to 4:3, does the file play back at 16:9?
Cheers No clue - how does it play in a standalone?

[SeeMoreDigital]

Originally posted by mpucoder
No clue - how does it play in a standalone? It plays back at 16:9 via my Pioneer DV-575A... But I've just noticed, so do five commercial 4:3 DVD's I tried :(

Jeez, my Sigma Xcard must be really quite clever :eek:

I don't know what to make of this!


Cheers

[Orion|69]

VIDEO_TS.VOB is just as often flagged as 16:9 as it is 4:3 - also when it doesnt actually consists video. Goes for PAL as well as NTSC.

There's no reason for it.. it's just what the original author did, coz he prolly felt like it or left room there for the company logo (which is often 16:9 even when the main feature is 4:3).

[Matthew]

Originally posted by buzzqw
just a question: could be possible (or not) in a near future to support sub/idx or srt subtitles ?

With sub/idx you can use vsconv.exe (command-line) or SubResync (GUI) to extract them to sst/bmp, which MuxMan supports. I'm not sure it flags forced subs correctly though (haven't tested that yet), but they can be extracted as a separate stream.

If I may suggest a feature to add to the current GUI: the ability to add a precommand that sets the default subtitle stream. Useful for foreign language films and movies like LOTR.

[mpucoder]

Originally posted by SeeMoreDigital
It plays back at 16:9 via my Pioneer DV-575A... But I've just noticed, so do five commercial 4:3 DVD's I tried :(
What are you judging them by? There is no such thing as a 4:3 or 16:9 DVD, each VTS can be either, the menues don't have to be the same as the titles, and the video manager does not have to agree either.
Further, the video itself, if meant for widescreen AND pan/scan is marked as 4:3 (with a picture width of 720, but display width of 540 - this signals pan/scan encoding)

[mpucoder]

There is a new bugfix available at the Muxman homepage (http://www.mpucoder.com/Muxman/)
It fixes the problem katjarella is having. In case you had as much trouble as I did grasping what the problem was, it boils down to extending a motion video (freezing it beyond its runtime), which is possible and allowable. The bug affects more than that, though, as it improperly joined GOPs together that it thought were short.

The bottom line is, you need this fix or risk non-compliant multiplexes.

[Orion|69]

Originally posted by mpucoder
There is a new bugfix available at the Muxman homepage (http://www.mpucoder.com/Muxman/)
It fixes the problem katjarella is having. In case you had as much trouble as I did grasping what the problem was, it boils down to extending a motion video (freezing it beyond its runtime), which is possible and allowable. The bug affects more than that, though, as it improperly joined GOPs together that it thought were short.

The bottom line is, you need this fix or risk non-compliant multiplexes.

I think I understand the problem, but what I dont understand is why it should be allowable. Wouldnt this be the same if the (or one of the) soundtrack(s) would be longer than the mpeg2-stream ? Wouldnt that be reason enough to throw it with an error message ? Or am i thinking in the complete wrong direction here ?

Anyway.. thanks for the swift bugfix. Appreciated :)

[mpucoder]

The last frame of video in a sequence can be held for any arbitrary amount of time, with or without audio. The bug wasn't about that ability, but that the vobu was not built correctly.

[Orion|69]

I read the older threads now too.. all of em.. I guess I owed u that much before I started asking stupid questions again :)

But now I understand what it was all about :)

I also dove into the Subresync / VsConv matter (just for PAL sofar - gonna check out NTSC after this post).

Guess what ? The two most used tools to create a stt for Scenarist and now ofcourse for Muxman too, are both NOT compliant, with VSConv being the lesser of two evils :

1) Subresync

st_format 2
Display_Start non_forced
TV_Type PAL
Tape_Type NON_DROP
Pixel_Area (0 573)
Directory .
Subtitle set1
Display_Area (0 2 719 575)
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 (4 4 4 3)
Contrast (15 15 0 15)


2) VSConv

st_format 2
Display_Start non_forced
TV_Type PAL
Tape_Type NON_DROP
Pixel_Area (0 573)
Directory C:\TARZAN\VIDEO_TS\4_is_2
Subtitle set2
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 (9 3 9 4)
Contrast (15 15 0 15)


a) Subresync & VSConv both set the wrong Pixel_Area for PAL.. should be (1 573)
b) Subresync sets the wrong Display_Area.. VSConv sets the correct one
c) Subresync doesnt use the correct conversion rule character.. it uses "-" where it should clearly be "=".. VSConv does that correct
d) Subresync doesnt set the correct Color values.. VSConv correct again (not that that is of big importance at the moment.. but it will be in the long run.
e) Subresync doesnt set the full path.. VSConv does.

VSConv wins 5-1 !

So.. use VSRip + VsConv for now.. I'll look into getting that small "bug" out of VSConv so it truly is Scenarist and thus Muxman compliant.

.....

1 small question about 0.12b too

when chosing the soundstreams - visually impaired ? should that be a choice for sound ? and where i would expect that as extension it isnt there.. the subs.

[mpucoder]

I'm glad someone is looking into the sub rippers. I tried to get Zuggy to fix SubRip, but no luck so far. At least the errors in it are predictable, so Muxman has a way to correct it (by using the "generator" statement).

Yes, visually impaired is for audio. These streams contain descriptive narration to help visually impaired people know what is going on in the movie. Visually impaired people can also use large subtitles or captions. Captions are intended for the hearing impaired. These contain more information than just dialog, such as descriptive text of sounds, like [door slams], or [stairs creaking].

[Orion|69]

haha :) i've seen loads of dvds but never encountered one yet which had that :)

it isnt a laughing matter actually, but i'm using no caps so they prolly can't read it anyway.

nobody requested the log to written in the dir where the mpeg2 stream is at btw? seems far more logical to me.. and less directory/disk hopping :)

[Matthew]

@Orion|69, something else which may be of interest to you is that vsconv does not flag individual subs as forced (they can only be extracted into a separate stream with the forced flag up top). Of course this isn't an issue of compliancy (and so does not affect MuxMan), just one of practicality :)

BTW SubRip is always 7 frames off (with PAL at least) when ripping directly from vobs (not from sub/idx).

[mpucoder]

The amount that SubRip is off depends on the authoring program, most will be off by 25257/90000 seconds. Here's the note in the readme file for Muxman:
Special note for users of SubRip 1.17.1
SubRip 1.17.1 has several errors in the sst file, wrong color mapping, syntax error in conversion
rules, and most noticable the times are neither relative to video start timecode (ie if movie
starts at 1:00:00:00, as many do, you must add 1 hour to all the times) or accurate. To correct for
this, add the following line in your sst file as the second line:
Generator SubRip1.17.1 25257

the last part, "25257" is a typical value for video delay (which SubRip does not account for), to
get the value use VobEdit, look at the first pack (NAV) and find "vobu_s_ptm" - this is the number
to use for your rip.

[Matthew]

7 frames x 40 ms=280 ms=25257/90000 seconds. Oops, I should have read the notes more carefully before mentioning that :)

Note that you can enter an offset in subrip to account for the start timecode being non-zero. vsconv starts at zero too. We re-encode with a start timecode of 00:00:00:00 anyway.

[Zeul]

You guys should check out the latest builds of vscon + vsrip (modified by d3s7). These fix a number of huge bugs and also label the bitmaps as highlight present if there is one (for BOV). Using the -numenu4u switch will also create the sst suitable for vobid demux. The timestamp is reset at every vobid. Also the endtime is now written as 99:99:99:99 if there is 'no stop' ie the sub stays until the end of the present cell.

[Orion|69]

Originally posted by Zeul
You guys should check out the latest builds of vscon + vsrip (modified by d3s7). These fix a number of huge bugs and also label the bitmaps as highlight present if there is one (for BOV). Using the -numenu4u switch will also create the sst suitable for vobid demux. The timestamp is reset at every vobid. Also the endtime is now written as 99:99:99:99 if there is 'no stop' ie the sub stays until the end of the present cell.

Was already looking at his modification of the two :) I will message him for sure :)

[Orion|69]

Originally posted by Matthew
@Orion|69, something else which may be of interest to you is that vsconv does not flag individual subs as forced (they can only be extracted into a separate stream with the forced flag up top). Of course this isn't an issue of compliancy (and so does not affect MuxMan), just one of practicality :)

I personally prefer that myself, but since D3s7 has agreed to provide me the code to his MOD of the two tools and is even willing to help it to be THE subrip/convert tool for Muxman too, I could look into that too :)

Btw : thanks D3s7 !

[mpucoder]

Well, while we're at it, Scenarist uses a different convention for a subpicture with no stop code. It uses a minus sign in the End Time column. btw that doesn't mean until the end of the cell, but until the next subpicture or end of cell. It's the only way to do 30fps subs.
I think today is a good day to publish what I have on the sst format, so I'll do that and post when it's available.

One document on the web that's fairly good is here (http://www.dvdmadeeasy.com/downloads/acrobat/SubtitleFileFormat.pdf)
It left out some statements (TV_Type and Tape_Type), but is otherwise very good, especially in explaining the pixel_area and display_area

[Matthew]

Originally posted by Orion|69
I personally prefer that myself, but since D3s7 has agreed to provide me the code to his MOD of the two tools and is even willing to help it to be THE subrip/convert tool for Muxman too, I could look into that too :)

Well it wouldn't have to be compulsory, it could be enabled using something like -flagforced.

I have my own crappy little easy way of fixing the problem (using batch file search and replace). I just think it is a good/necessary feature to implement, if you are going to be modifying it anyway :)

[Orion|69]

Wtd...


MuxMan version 0.12b
Accepted video C:\MUXTEST\NTSC_720x480.m2v size = 4214961385
Accepted audio C:\MUXTEST\Audio_English_Delay_-83ms.ac3
Opened sub 1 file C:\MUXTEST\CRIMSON_NTSC\VSCONV_ENGLISH\1.sst.
Opened sub 2 file C:\MUXTEST\CRIMSON_NTSC\VSCONV_FRENCH\2.sst.
Opened sub 3 file C:\MUXTEST\CRIMSON_NTSC\VSCONV_SPANISH\3.sst.
Opened sub 4 file C:\MUXTEST\CRIMSON_NTSC\SUBRIP_ENGLISH\sr.sst.
15:55:59 Begin multiplex.
Maximum audio duration 375764 fields.
new graphics buffer size 414720.
15:56:00 starting video file number 1.
Cell map size 50.
End of video file
Bytes remaining in buffer = 0.
16:55:38 End multiplex.
Bitrate - avg: 5700224, min: 360087 (lba 0), max: 9525962 (lba 2080125).
Shortest GOP has 3 fields, longest GOP has 58 fields.
Fields: 375750, VOBU: 12521, Sectors: 2180991.
Largest GOP of 58 fields exceeds DVD specification of 36.
Resulting DVD is non-standard.


58 ?

Gonna run the Philips thingy over the input and the output, coz 58 seems very strange to me.

-edit-

I had 1 machine free so I ran Bitrate Viewer over it and wrote a quick parser to display totals for the GOP's.. this is what it said.


Input m2v - Original DVD5 Crimson Pirate NTSC - demuxed with Smartripper 2.41
GOP list created with Bitrate Viewer 1.5.054 - parsed with GOPlistparse.c


Ammnt ## Order Closed
-----------------------------------------
3 1 I Yes
2 2 IB No
4 3 IBB No
3 5 IBBPB No
2 6 IBBPBB No
3 7 IBBPBBP No
4 9 IBBPBBPBB No
3 10 IBBPBBPBBP No
25 10 IPBBPBBPBB Yes
22 11 IBBBBPBBPBB No
1 12 IBBPBBPBBPBB Yes
12.451 12 IBBPBBPBBPBB No
16 13 IPBBPBBPBBPBB No
2 23 IBBPBBPBBPBBBBPBBPBBPBB No

total ammount of GOP's : 12.541


No idea if the outputted data by Bitrate Viewer is correct so I'll run some more tests.

DVD-Video Verifier still running on my demuxed m2v.
Need to do that for the created VOB's too.

-edit-
well.. that were the shittiest 4 hours spent ever :)
seems the philips tool was hanging for almost the complete time and i didnt notice :)

I'll have to find another way to get the GOP specs from the muxed output VOBS

-edit-
Used IfoEdit function now : it's not getting any clearer coz there's a whole lot of difference.


Output VOB's - Remuxed DVD5 Crimson Pirate NTSC - Remuxed with Muxman 0.12b
GOP list created with IfoEdit 0.971 - parsed with GOPlistparse2.c

Ammnt ## Order Closed
-----------------------------------------
3 1 I ?
2 2 IB ?
4 3 IBB ?
3 5 IBBPB ?
2 6 IBBPBB ?
3 7 IBBPBBP ?
4 9 IBBPBBPBB ?
3 10 IBBPBBPBBP ?
15 10 IPBBPBBPBB ?
1 11 IBBBBPBBPBB ?
2 11 IBBPBBBBPBB ?
1 11 IBBPBBPBBBB ?
5 11 IBBPBBPBBPB ?
3 11 IBBPBBPBPBB ?
4 11 IBBPBPBBPBB ?
5 11 IBPBBPBBPBB ?
1 12 IBBBPBBPBPBB ?
12.451 12 IBBPBBPBBPBB ?
1 13 IBBBPBBPBBPBB ?
2 13 IBBPBBBPBBPBB ?
4 13 IBBPBBPBBBPBB ?
3 13 IBBPBBPBBPBBB ?
3 13 IBBPBBPBBPBBP ?
1 13 IBBPBBPPBBPBB ?
1 13 IBBPPBBPBBPBB ?
1 13 IPBBPBBPBBPBB ?
2 23 IBBPBBPBBPBBBBPBBPBBPBB ?

total ammount of GOP's : 12.530


Output would have 11 GOPs less ? Basically I don't know what to believe now, but the reported 58 fields by Muxman 0.12b aint really believable either.

-edit-
IfoEdit has a "Check m2v"-function too.. and that gives us yet another output


Input m2v - Original DVD5 Crimson Pirate NTSC - demuxed with Smartripper 2.41
GOP list created with IfoEdit 0.971 - parsed with GOPlistparse2.c

Ammnt ## Order Closed
-----------------------------------------
4 1 I ?
2 2 IB ?
4 3 IBB ?
3 5 IBBPB ?
2 6 IBBPBB ?
3 7 IBBPBBP ?
4 9 IBBPBBPBB ?
3 10 IBBPBBPBBP ?
25 10 IPBBPBBPBB ?
1 11 IBBBBPBBPBB ?
1 11 IBBPBBPBBBB ?
2 11 IBBPBBBBPBB ?
5 11 IBBPBBPBBPB ?
4 11 IBBPBPBBPBB ?
3 11 IBBPBBPBPBB ?
5 11 IBPBBPBBPBB ?
1 12 IBBBPBBPBPBB ?
12.456 12 IBBPBBPBBPBB ?
1 13 IBBBPBBPBBPBB ?
2 13 IBBPBBBPBBPBB ?
4 13 IBBPBBPBBBPBB ?
2 13 IBBPBBPBBPBBP ?
1 13 IBBPBBPBBPPBB ?
1 13 IBBPBBPPBBPBB ?
3 13 IBBPBBPBBPBBB ?
1 13 IBBPPBBPBBPBB ?
1 13 IPBBPBBPBBPBB ?
2 23 IBBPBBPBBPBBBBPBBPBBPBB ?

total ammount of GOP's : 12.547


I'll see what DGIndex does too on input-m2v / output vobs

[Orion|69]

Originally posted by Matthew
Well it wouldn't have to be compulsory, it could be enabled using something like -flagforced.

I have my own crappy little easy way of fixing the problem (using batch file search and replace). I just think it is a good/necessary feature to implement, if you are going to be modifying it anyway :)

You are right there. Unfortunately I haven't started yet, coz I didnt get the sources yet from D3s7 :)

The moment I do I'll start :)

[D3s7]

Probably won't be till this weekend...

I've got to clean up the source enough so you can figure out what's changed and rar it up...

course first I gotta remember what all I changed :)

[Orion|69]

Originally posted by D3s7
Probably won't be till this weekend...

I've got to clean up the source enough so you can figure out what's changed and rar it up...

course first I gotta remember what all I changed :)

No problem at all, subs are patient.. so am I :)

[CoNS]

I'm adding custom subs to a disc. It has 1 VTS and 1 PGC inside the VTS. I use PgcDemux latest version to demux. It tells me the PGC has an audio delay of -92. I usually use IfoEdit DVD author function to remux. I specified -92 ms as audio delay, but when I later loaded the output in PgcDemux again, it had a much higher audio delay, something like -179.

I then downloaded MuxMan and tried this neat proggy. This time, the specified audio delay of -92 became -79 in the outout disc. No errors were encountered during any of the remuxing processes. What can be causing the incorrect audio delay? :confused:

[mpucoder]

You've been around long enough to know not to crosspost.

The problem is probably in PgcDemux, but I am waiting for jsoto to read the post in IFO/VOB editors.

[sweetness]

muxman creates still images to 4:3. can it create a 16:9 stills?
thanks

[mpucoder]

Yes, it can, but currently you have to trick it. If you are using the gui, along with your bmp open any 16:9 m2v file. Allow Muxman to check it (ie close the file list dialog box), then open the file list again (click on ... on the video line) and remove the file.

Eventually there will be a dialog box to view and set attributes for images.

There is a bug which prevents version 0.12 from setting 16:9 for stills from a project file. That has been fixed in Muxman 0.12c and will be released within the hour. To specify a 16:9 use one of the following lines in the video segment section:
Display Mode=P/S and LB
Display Mode=Only Panscan
Display Mode=Only Letterbox

[SeeMoreDigital]

Originally posted by mpucoder
Eventually there will be a dialog box to view and set attributes for images.

There is a bug which prevents version 0.12 from setting 16:9 for stills from a project file. That has been fixed in Muxman 0.12c and will be released within the hour. Nice!

Will we still be limited to inputting 720x480/576 BMP images? How about JPG, GIF, PNG etc. And images with bigger resolutions?


Cheers

[mpucoder]

It will do resizing, but you might not like the results (if so, use a graphics editor before Muxman)
As for formats, jpg is a nice possibility as most jpg can be converted to mpeg without any additional loss (both jpeg and mpeg use the same color space and DCT, only the final encoding is different).
gif is a possibility if UniSys's copyright has expired.
I've looked at png, that will take some time for me to understand (note, in the past I wrote image processors for DOS using bmp, gif, and jpg)

[mpucoder]

Now that 0.12c is out here is another way to change to 16:9 without a video file. Set everything up the way you'd like, then save the project to some file. Edit the file so that the Display Mode is one of the three in my earlier post, then reload the project file. You don't need to close Muxman in between.

[katjarella]

Thanks for fixed 16:9 display modes for stills from project file

my wish list:
* support of "all" Video Resolutions (480x etc)
* create Stills as MPEG1
* selectable instruction : Duration or *Frame (Video List).
* Auto Create Chapter from Video or Audio List
* muxman Projekt:
*Layout Info { Target Directory= }
Item=PGC{ Pre Command= Post Command= PG Playback Mode= Repeat Times= PGC Still Time=}
later + Cell Command= Next PGC= Prev PGC= Goup PGC=

* IMPORTANTLY

[CoNS]

Originally posted by mpucoder
You've been around long enough to know not to crosspost.

The problem is probably in PgcDemux, but I am waiting for jsoto to read the post in IFO/VOB editors. No problem, we'll take the discussion there. About cross posting: I initially wrote about the problem in PgcDemux. Afterwards I got to think about the fact that MuxMan is involved in a way that you could be interested in, and so I searched the forum for a MuxMan thread and posted the question here, too, to make sure you'd notice. Anyway, I've replied in that other thread now. :)

[dragongodz]

* support of "all" Video Resolutions (480x etc)
since Muxman is a DVD authoring program 480x is not a standards valid resolution. that is specifically for SVCD.

[katjarella]

Originally posted by dragongodz
since Muxman is a DVD authoring program 480x is not a standards valid resolution. that is specifically for SVCD.

I am aware of that. Maybe it is possible to disable the check of the resolution, though.

PS: I have accustomed myself that not all of my wishes come true. :)

[rasta21]

...i run muxman on my 128mb encoding machine...so here my little wishlist.

*set priority option (realtime /high /normal /low)
*status display when minimized to taskbar. (%) display in taskbar for example

[CoNS]

Thx for this great program, mpucoder. I have a couple of requests:

- Function to import ifo subtitle colours (like loading chapters, in File menu).

- Option to force selected subpic stream on.

[fluffysnurgle]

Is there any way to use Muxman to make DVDs which have multiple titles and possibly even menus? Muxman is a very good program, but one plain title on the disk isn't really enough for what I need now.

Thanks :)

[Zeul]

fluffysurgle.
Muxman will eventually be a complete authoring tool, but at the moment Mpucoder has been making sure that the authoring engine works properly, and so it is tested in a single VTS environment. Multiple VTS will come, and so will menus at some point.

[fluffysnurgle]

Thanks Zeul :)

What I have been doing is:
1) Multiplex each title with Muxman separately
2) Make an ISO for it
3) Use a DVD ripper to join the multiple VOBs into a single file
4) Pass the newly-joined VOB to DVDAuthor

This works well enough; but is a lot of steps. Unless there is a way to stop Muxman splitting VOBs at the 1GB boundary (in which case the VOB could be passed to DVDAuthor directly; but I think the 1GB file size is a DVD-Video requirement) I guess it will have to do.

[Jeffster]

I think there may be a small bug in the way muxman concatenates video files. I don't know if it's of any consequence to the final DVD but I thought I'd mention it.

If I demux the VOB created by muxman and import the m2v into other programs, the length of the video file isn't recognized correctly, instead the reported length of the m2v appears to be that of the first video file that was added to muxman not the combined length.

[SeeMoreDigital]

It's already possible to use Muxman to add/join multiple de-muxed .m2v and .ac3 streams (from .vob files) into a single stream ;)


Cheers

[mpucoder]

What your other programs are seeing is the end_of_sequence that appears after each video file. If each file does not have an end_of_sequence, one is added otherwise the video verifier reports an error (due to the unexpected jump in the GOP timecode).

Since the stated purpose of Muxman is to make DVDs, this means it is not a bug.

If you want to join video files together for another program you should be using a video editor. They are designed to produce an entirely new sequence.

[Jeffster]

Thanks for the explanation.

[Gusy]

what kind of bitmaps does muxman support when using .sst files? I've been using 4 bit BMPs but it would be nice if I could use other kind of bitmap (higher palette BMPs or file types).

[mpucoder]

4-bit rgb or rle, Windows or OS2 format. Other color depths could have been supported, but I saw little sense in that since they get reduced to 4 colors.

[Trahald]

Originally posted by mpucoder
What your other programs are seeing is the end_of_sequence that appears after each video file. If each file does not have an end_of_sequence, one is added otherwise the video verifier reports an error (due to the unexpected jump in the GOP timecode).

Since the stated purpose of Muxman is to make DVDs, this means it is not a bug.

If you want to join video files together for another program you should be using a video editor. They are designed to produce an entirely new sequence.

with the install of batchencodem2v i have it comes with revpulldown.exe i modified from pulldown and it has a flag -ignoresequenceendcode which will remove all endcodes and add one to the end. (rev)pulldown naturally redoes timecodes which will help also.

[CoNS]

mpucoder, what do you think about my suggestions about importing subtitle colours from ifo (like ReJig does, very useful feature), and setting forced subtitle and/or audio stream?

[katjarella]

Dear mpucoder,
something is wrong with your chapter assignment. After multiplexing, the target chapters don't match the source chapters. And yes, I checked the MPEG for the presence of I frames at those places.
Original,IfoEdit,DVDMaestro | Muxman 0.12/0.13pa | Muxman Scene List
[Pos: 00:00:07.07] [Frames: 182] | [Pos: 00:00:07.07] [Frames: 182] | Scene Time=00:00:07:07
| *** |
[Pos: 00:20:33.11] [Frames: 30836] | [Pos: 00:20:33.11] [Frames: 30836] | Scene Time=00:20:33:11
[Pos: 00:22:14.18] [Frames: 33368] | [Pos: 00:22:15.08] [Frames: 33383] | Scene Time=00:22:14:18
[Pos: 00:29:26.12] [Frames: 44162] | [Pos: 00:29:26.12] [Frames: 44162] | Scene Time=00:29:26:12
| *** |
[Pos: 00:44:02.09] [Frames: 66059] | [Pos: 00:44:02.09] [Frames: 66059] | Scene Time=00:44:02:09
[Pos: 00:50:13.02] [Frames: 75327] | [Pos: 00:50:13.17] [Frames: 75342] | Scene Time=00:50:13:02
[Pos: 00:54:17.22] [Frames: 81447] | [Pos: 00:54:17.22] [Frames: 81447] | Scene Time=00:54:17:22
I repeated this test several times, and almost always got different results.

Furthermore, sometimes the duration is parsed improperly during import. Could it be possible to change the handling to frames, or add the possibility to manually enter a frame count?

Thanks Katjarella

[mpucoder]

The accuracy of chapter placement has been on my todo list at a low priority for some time now. Chapters can start only at a new VOBU, and currently the VOBU planning logic does not take into account desired chapter points when deciding which gops go where. More than likely the desired I frame is in the middle of the preceeding VOBU.

Duration is very sensitive to a statement that preceeds it, the standard declaration. As another user found out the hard way, syntax is very important (to all statements, but this one is hard to catch). The statement must read:
Standard=PAL
without any spaces to be interpretted correctly, otherwise NTSC is assumed. The statement affects parsing only, as it is overridden later by the file properties. This is what makes it hard to notice, as the final product will say PAL if PAL sources were used.

edit: also wanted to make clear that at this time duration cannot be used to shorten motion video, it's only use is to hold video.

[CoNS]

A possible bug in MuxMan beta 0.12d:

I've used MuxMan about a dozen times now, with great results. Very fast and reliable tool. Only, on this last disc I tried, the subtitle stream is somehow not included in the output. I've tried twice, no luck.

It's a plain and simple case, like the other ones I tried: A single NTSC video file, one audio stream and one subtitle stream. The video and audio stream is demuxed from an original disc using PgcDemux, from which I also import celltimes. The subtitle stream is custom made by me. MuxMan checks "LB" for the video stream, and I select "LB" and "Wide" for my subtitle stream and of course specify language etc.

When I play the output in my software player (MPC), the subtitle stream is selectable in the navigation, but no suppic is displayed. At first I thought it was because of a wrong vertical positioning setting in my subtitle creation tool (SubtitleCreator by Paddington), but I've created hundreds of subtitles before this one with the exact same settings. I've checked that the subs I'm using are not out of sync. I've also checked that the .sup file created by SC actually does contain the bitmap subs as it should.

And when I try to demux the output created by MuxMan using PgcDemux, I tells me that there're no subtitle streams present, which is why I suspect MuxMan causing the problem.

One thing is different from all the other discs I've muxed using MuxMan: My audio stream is a .mpa file (MPEG, DD2.0), and thus the original disc and MuxMan places the stream as #C0, not #80. All the other discs I've muxed in MuxMan have had ac3 audio. Could this be causing the problem?

mpucoder, please let me know if you need any further info. In the meanwhile I'll try muxing it with IfoEdit and check if the subs are there...

BTW, mpucoder, whaddayathink of my suggestion about adding support for import of ifo colours? And perhaps a setSTN precommand?

[mpucoder]

I just tried an .mpa and .sup and the subs do disappear, so there is a bug (most likely, since .mpa and subs share a common header, that the subs are in the wrong stream)

All the stuff you are waiting for is coming, pre-release 0.13 imports colors the Scenarist way - ie by the .scp or .mxp files. Commands, navigation, highlight is all in the works, but requires replacing the canned ifo file generator with a compiler.

[CoNS]

Yep, my subs work with IfoEdit...

About import of subtitle colours: I don't have experience with Scenarist. Is it going to work like ReJig (and SubtitleCreator), where you can simply point to an .ifo file, and the program will read and use the subtitle colours from it? This way works very well in the aforesaid programs, I think.

EDIT: Is the prerelease of v0.13 available at the present time?

[mpucoder]

The colors get set by modifying the DefaultPalette. In mxp it looks like this:

Section=Settings
{
Item=Palette
{
Name=DefaultPalette
Color 0=0, 0, 255
Color 1=255, 0, 0
Color 2=0, 0, 0
Color 3=255, 255, 255
Color 4=0, 255, 0
Color 5=255, 0, 255
Color 6=255, 255, 0
Color 7=0, 125, 125
Color 8=125, 125, 125
Color 9=225, 225, 225
Color 10=125, 0, 0
Color 11=0, 125, 0
Color 12=0, 0, 125
Color 13=222, 0, 255
Color 14=222, 125, 0
Color 15=125, 0, 125
}
}


Pre-releases are available to members of my forum. 0.13 will be released on Monday.

Version 0.12e fixes the problem with mpeg audio and subpictures along with a fix to 4:3 video attributes (they were not spec, but DVD players don't check)
Available at the Muxman homepage (http://www.mpucoder.com/Muxman/)

[buzzqw]

i had a problem too :scared: .. with subtitles

till 0.12b i used to vsrip subtitles, then with vsconv transform this idx/sub in a sst file and many bmp.

but with the change of 05/03/04 (0.12c) "conversion rules are now working in sst files"

my subtitles isn't visible. i suppose it get muxed ( i can see this in muxman log) but i cannot see more

i use vsrip/vsconv bundled with latest scenaid (1.5.0.20)

here the muxman log:

MuxMan version 0.12e
Opened script file D:\dvdmagic\zdvd.mxp
Accepted video d:\dvdmagic\movie_dvd.m2v size = 177620896
Accepted audio d:\dvdmagic\audio.ac3
Opened sub 1 file d:\dvdmagic\ita.sst.
Pixel_Area values 0 573 are incorrect, using default of 0 572.
09:28:22 Begin multiplex.
Maximum audio duration 28480 fields.
new graphics buffer size 414720.
09:28:23 starting video file number 1.
SeqEnd at A96479C.
Bytes remaining in buffer = 0.
09:28:52 End multiplex.
Bitrate - avg: 5300631, min: 3304106 (lba 59158), max: 8028160 (lba 58864).
Shortest GOP has 14 fields, longest GOP has 30 fields.
Fields: 14202, VOBU: 475, Sectors: 91894.

here is the start of my sst file

st_format 2
Display_Start non_forced
TV_Type PAL
Tape_Type NON_DROP
Pixel_Area (0 573)
Directory D:\dvdmagic
Subtitle ita
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 (14 15 16 13)
Contrast (0 0 0 0)
0001 00:00:00:04 00:00:00:05 ita_0001_v001_c001.bmp
Contrast (15 15 15 0)
0002 00:00:01:24 00:00:04:13 ita_0002_v001_c001.bmp
0003 00:00:04:18 00:00:07:18 ita_0003_v001_c001.bmp
0004 00:00:07:23 00:00:10:07 ita_0004_v001_c001.bmp

Thanks

BHH

[mpucoder]

This is a common syntax error with many rippers, SubRip and vsrip among them. And it wouldn't work right in Scenarist, either. The conversion rules, which are the relational operators following the color values, must be seperated by a blank. ie

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

should be

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

This is so common that Muxman includes a statement to tell it what generated the sst file. In version 0.12 only SubRip1.17.1 is recognized, and the syntax and logical errors corrected. Version 0.13 will also recognize vsrip and treat each character as a new rule.

[buzzqw]

A big Thanks !!!

BHH

EDIT : will muxman autodetect/autocorrect this error or user must place somewhere in sst a note as for SubRip:"To correct for this, add the following line in your sst file as the second line:
Generator SubRip1.17.1 25257" ?

I hope for an automatic solution...

tahnks anyway

BHH

[mpucoder]

In 0.13 if you add "Generator vsrip" the conversion rules without spaces will work. I really would like all the sub ripping programs to correct these and other errors, though, as these scripts DO NOT work unmodified with Scenarist.

[buzzqw]

D3s7 has corrected vsconv !!!

http://forum.doom9.org/showthread.php?s=&postid=630844#post630844

now vsconv create a correct sst file (watch down in post)

would be possibile (in command line mode and gui) order to muxman from what ifo must copy subs color (if isn't to much to ask) ?

Great work Mpucoder ! thanks to you and D3s7 !

BHH



st_format 2
Display_Start non_forced
TV_Type PAL
Tape_Type NON_DROP
Pixel_Area (0 573)
Directory d:\dvdmagic
Subtitle 2
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 (14 15 16 13)
Contrast (0 0 0 0)
0001 00:00:00:04 00:00:00:05 2_0001_v001_c001.bmp
Contrast (15 15 15 0)
0002 00:00:01:24 00:00:04:13 2_0002_v001_c001.bmp