Muxman version 0.12 released

[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