Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
|
|
Thread Tools | Search this Thread | Display Modes |
5th May 2009, 09:55 | #323 | Link |
Registered User
Join Date: Apr 2009
Posts: 17
|
@0xdeadbeef: Great program, very handy for BD to DVD conversions. One thing though: On VobSub-Export, could you use a Padding Stream (i.e. 0x000001BE) instead of just stuffing 0xFF's till the pack end?
Last edited by prenz; 5th May 2009 at 10:39. |
5th May 2009, 11:34 | #324 | Link | ||
Author of BDSup2Sub
Join Date: Jun 2003
Posts: 478
|
Quote:
Quote:
I'm not sure if I can follow you here. The packets/segments are aligned to 0x800 so unused part of a package is filled with padding bytes. In all the samples I saw, 0xff is used as padding byte - probably as this is also the end command. |
||
5th May 2009, 13:15 | #325 | Link |
Registered User
Join Date: Apr 2009
Posts: 17
|
Deadbeef, this is about the calculation of stream lengths. Let me show a subtitle pack (this is from DVDLab, as displayed by VobEdit):
Code:
[Pack Header] [0000] Pack identifier (start code) 442 [000001ba] [0004] SCR (System clock reference) 68 2 156 173 181 99 [44 02 9c ad b5 63 ] SCR 02725302.177 [000a] Program Mux Rate: 25200 (1260000 BPS) (10080000 bps) 1 137 195 [01 89 c3 ] [000d] Pack stuffing length: 0 248 [f8] [Private Stream 1] [000e] Private Stream 1 start code 445 [000001bd] [0012] Length 1728 [06c0] Code:
[Padding Stream] [06d4] Padding Stream start code 446 [000001be] [06d8] Length 294 [0126] |
5th May 2009, 13:30 | #326 | Link | |
Registered User
Join Date: May 2008
Posts: 1,840
|
Quote:
As for as export I agree writing an ifo would be a mess but there's an alternative at least with pgcedit by importing/exporting raw clb or rgb txt files. |
|
5th May 2009, 14:00 | #327 | Link | |
Registered User
Join Date: Sep 2003
Location: On The Beach
Posts: 714
|
Quote:
So, if first line start with: 00:00:00,000, to have in the saved SUP: 00:00:00,300 In my tests with MPC-HC and tsmuxer are some problems and also my TViX refuse to play this file and I suspect the problem is that 000 ms. 300 ms can't harm the reading of a subtitle. enjoy, Mtz |
|
5th May 2009, 17:16 | #328 | Link | |||
Author of BDSup2Sub
Join Date: Jun 2003
Posts: 478
|
Quote:
Quote:
Quote:
|
|||
6th May 2009, 18:30 | #329 | Link |
Author of BDSup2Sub
Join Date: Jun 2003
Posts: 478
|
06.05.2009 3.5.1 -> 3.5.2
|
7th May 2009, 08:24 | #330 | Link | |
Registered User
Join Date: Apr 2009
Posts: 17
|
Quote:
You'd be amazed what VobEdit will import. Contrary to its name it will edit any program stream you feed it (but indeed, it will crash on displaying packs #2-n of a .sub that doesn't use a padding stream). You mean if the VobSub used a padding stream? Why do you think so? Anyway, I'd wager against it. I'm convinced that a VobSub-Import would simply ignore anything after the end of the pack's subtitle stream (including a padding stream or plain 0xFF-Padding), and will look for the next stream at the file position given from .idx. At least BDSup2Sub and SubResync will import a VobSub + padding stream without problems. |
|
7th May 2009, 11:34 | #331 | Link |
Author of BDSup2Sub
Join Date: Jun 2003
Posts: 478
|
Hm, I would assume that by adding the padding bytes, the SUB would get very close to a (DVD-)SUP. I never really examined the DVD-SUP format closely enough to tell for sure. I kinda fear that if I go in that direction people will jump onto the bandwagon and insist that the SUB is a 100% consistent and muxable DVD SUP stream. And this idea honestly gives me headaches.
BTW: Did you test if tools like MKVMerge and SubtitleCreator accept SUB files with padding? If so, I might consider adding the padding (and it rhymes, too). |
7th May 2009, 12:34 | #332 | Link |
Registered User
Join Date: Sep 2008
Location: Sweden
Posts: 66
|
BDN XML import
0xdeadbeef,
BDSup2Sub only treats a "PAL" XML file correctly on import if the video format is specified as "576p" in the XML file. If the video format is specified as "576i" (which is the correct way to specify the format), BDSup2Sub seems to assume that the import format is 1080p. Could you correct this? I guess it's the same thing with "480i", but I haven't tried it. |
7th May 2009, 17:47 | #334 | Link |
Registered User
Join Date: Mar 2008
Posts: 305
|
Do you think it would be possible, when executing say:
java.exe -jar BDSup2Sub.JAR '*.sup' '*_FORCED.sup' /res:1080 /forced to not stop when Code:
#> 1542 (01:38:51.217) ERROR: No forced subtitles found. Press any key to continue . . . that would be great. |
7th May 2009, 18:59 | #337 | Link |
Author of BDSup2Sub
Join Date: Jun 2003
Posts: 478
|
Just two quick fixes, untested. Ulf, mrr19121970 please have a look.
07.05.2009 3.5.2 -> 3.5.3
Last edited by 0xdeadbeef; 7th May 2009 at 19:22. |
8th May 2009, 07:53 | #340 | Link |
Registered User
Join Date: Dec 2005
Posts: 8
|
Thank you for this excellent program. It works fine, but... (there's always a "but" :-))
I have tried - unsuccessfully - to use this program to deliver something that I can process further with SubRip to do OCR scanning of the subtitles, but so far without any luck. I have tried 720p SUB/IDX, which kinda works, but for some pics SubRip seems to not be able to decode the file properly (shows garbage). The PAL output seems to be processable, but due to the resizing, it is quite often that SubRip can't recognize the same letter as being such, which leads to an awful lot of manual entering of letters. 1080p SUB/IDX doesn't seem to be supported at all by SubRip. I have also tried the PNG output, which I then converted to BMP using PMView (again 720p), but these files doesn't seem to be properly read by SubRip either. Would it be possible to have your program output SUB/IDX files in a format compatible with SubRip (f.ex. without RLE encoding or something like that?). Or if anyone knows about another utility that can du OCR processing on the SUB/IDX files created by BDSup2Sub (preferably the 1080p versions, as these should be clearer and thus easier to do successful OCR processing on). |
|
|