View Full Version : Muxman version 0.12 released
mpucoder
27th February 2005, 20:43
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
27th February 2005, 21:53
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
27th February 2005, 22:15
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
27th February 2005, 23:08
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
27th February 2005, 23:12
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
27th February 2005, 23:21
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
27th February 2005, 23:56
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
28th February 2005, 00:00
@katjarella - I think I fixed the tv standard problem. Any fixes after this will get a new revision.
Matthew
28th February 2005, 00:00
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
28th February 2005, 00:04
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
28th February 2005, 00:05
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
28th February 2005, 00:09
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
28th February 2005, 00:33
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
28th February 2005, 01:04
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
28th February 2005, 01:15
A BIG thanks. I'll give it a try in CLI mode..
jsoto
Matthew
28th February 2005, 01:25
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
28th February 2005, 01:29
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
28th February 2005, 02:14
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
28th February 2005, 02:37
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
28th February 2005, 02:47
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
28th February 2005, 02:54
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
28th February 2005, 06:53
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
28th February 2005, 07:17
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
28th February 2005, 07:29
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
28th February 2005, 08:22
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
28th February 2005, 08:24
Thanks for the feedback - time to rest for now.
Orion|69
28th February 2005, 10:07
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
28th February 2005, 12:26
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
28th February 2005, 13:04
Thanks mpucoder,
Still loving it... Great work indeed :D
Cheers
Orion|69
28th February 2005, 13:05
My bad :)
They should install the mod so u can search in the thread itself :)
mpucoder
28th February 2005, 14:55
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
28th February 2005, 15:22
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
28th February 2005, 17:27
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
28th February 2005, 19:59
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
28th February 2005, 20:02
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
28th February 2005, 20:08
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
28th February 2005, 20:14
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
28th February 2005, 20:15
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
28th February 2005, 21:05
Check your PM, there is an experimental build to see if alternate_scan vs zig_zag is the problem.
SeeMoreDigital
28th February 2005, 21:20
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
28th February 2005, 21:28
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
28th February 2005, 22:10
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
28th February 2005, 23:01
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
28th February 2005, 23:17
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
1st March 2005, 00:09
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
1st March 2005, 00:14
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
1st March 2005, 00:55
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
1st March 2005, 01:24
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
1st March 2005, 04:42
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
1st March 2005, 05:10
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].
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.