VideoHelp Forum
+ Reply to Thread
Results 1 to 9 of 9
Thread
  1. Member
    Join Date
    Apr 2007
    Location
    United Kingdom
    Search Comp PM
    Hi folks,

    This is a really really strange one that I'm hoping someone can shed some light upon. I have a couple of workarounds, so it's not an end-of-the-world scenario, but it is one of the oddest things I've seen in many a year and I have no real clue as to what's causing it.

    I have an MKV file, ripped from NTSC BluRay and containing embedded English subtitles for the non-English dialogue. I would tell you what the file is but I may not be allowed to because... you know, reasons. Ahem.

    I'm converting this to an NTSC DVD5 using the following method:
    • Rip the subtitles to an .SRT file using MKVExtractGUI2.
    • Convert the .SRT to .SUP using Txt2Sup. Font is Tahoma 20 point with an outline level of 2.
    • Create a DVD5 from the original MKV and the SUP using SVCD2DVD.
    • Change the subtitle colours by editing VTS_PCGITI/VTS_PGC1 using IFOEdit.
    • Make the subtitles (stream 1) permanently on by adding a Pre Command, also using IFOEdit.
    (Before anyone pitches in, I know there are newer and/or arguably easier tools to use than some of these. But I particularly like SVCD2DVD because it renders NTSC film sources at 29.97fps instead of 30fps like most other converters. This keeps the subtitle timings intact, as well as giving much smoother video on vertical panning shots).

    So far so good, but here's where it all gets a bit odd. One of the subtitles (and the sharper among you may recognise the source from this) is as follows with this exact punctuation:

    Code:
    -German beer.
    -Of course.
    If I play back the DVD created using this method, this subtitle and all subsequent subtitles will fail to display. The subtitles before it play fine. This is true for VLC Media Player on the PC and two standalone players, one Pioneer DVD player and one Toshiba Blu-Ray. Other subtitles can be forced to play by jumping around using the scrubber on VLC or the chapter controls on the players, but if the file is allowed to play through this subtitle normally, it kills the subtitle display.

    It gets stranger. If I change the text of either of those lines to anything else, the subtitles will play fine. During my experimentation I tried removing one or both leading hyphens, changing the text on the first line to "French beer", "German bier", "Germany beer", "Herman beer" and a fair few others, and removing the trailing periods. All of these modifications gave outputs that played fine. Similarly when I left "German beer" alone and inserted random characters into the second line, the subtitles were fine.

    If I exchange characters e.g. "Gernam beer" or "German bere" this does not cure the problem.

    If I change the timestamp to move this subtitle to somewhere else in the file, this does not cure the problem either.

    If I change the font size to 21 point or 19 point during the .SRT to .SUP phase, this does cure the problem.

    If leave the font size at 20 and change the font from Tahoma to Verdana, this also cures the problem.

    Even more frustratingly, if I open a set of problematic VOB files with SubRip and look at the contents, the overlays appear fine. No corruption, no missing subtitles. To the mark one human eyeball everything looks to be where it should. It's almost as though that particular choice of font size, specific characters and maybe even screen position is creating a unique string of bytes in the .SUP file that the subtitle overlay code is choking on once it's merged with the MPEG video. I've never come across anything like this before, affecting both software and hardware players.

    The only things I haven't yet tried are changing the outline level during the .SRT to .SUP conversion, or moving the whole subtitle left or right by a few pixels. If my theory is right one or other of these might also cure the problem, as they might change any problematic byte stream that the player has to read in order to display the subtitle overlay. But it's a total shot in the dark at this point.

    Has anyone else come across something like this before? It's certainly a new one on me. My workaround for this particular project, because I'm a bit OCD and like all my subtitles to be 20 point Tahoma, is to change the first line into a question, "-German beer?". It doesn't change the context of the scene and it prevents the subtitle generator from falling over.

    Any input would be appreciated. I'm happy with the workaround(s) but annoyed that I can't explain the problem. It also means I'm going to have to check all of my future projects to make sure no rogue subtitles are lurking in there.
    Quote Quote  
  2. DECEASED
    Join Date
    Jun 2009
    Location
    Heaven
    Search Comp PM
    Originally Posted by denali View Post
    [*]Convert the .SRT to .SUP using Txt2Sup.
    Create a DVD5 from the original MKV and the SUP using SVCD2DVD.
    Drop Txt2Sup, or SVCD2DVD, or both.

    I've never used SVCD2DVD, but I do have used Txt2Sup, and I know that it suXXX.
    Quote Quote  
  3. Banned
    Join Date
    Oct 2004
    Location
    Freedonia
    Search Comp PM
    I've seen bizarre, seemingly inexplicable subtitle problems caused by a subtitles file having invisible special characters in it. Editing a subtitle file in Linux or Mac and moving it to Windows or vice-versa can lead to this because of differences in end of line characters. Your problem meets my "inexplicable" criteria and some of the changes you make that work could be removing a bad character that is causing problems. I don't know of a good way to fix this kind of problem because vi under Linux or Mac can be used to highlight these characters so you can find them and get rid of them (vi is a text editor program) but as running vi under Windows is generally beyond most people's ability, you may be kind of stuck. There's a gui somewhere for the Windows version of vim (vim is free vi clone) and if you get really desperate, you could install it and use it to try to find unprintable characters on the lines in question and then manually remove them.
    Quote Quote  
  4. Member racer-x's Avatar
    Join Date
    Mar 2003
    Location
    3rd Rock from the Sun
    Search Comp PM
    Change it to Budweiser and call it a day

    Sorry, I have no significant contribution to this thread, nor do I care really..................
    Got my retirement plans all set. Looks like I only have to work another 5 years after I die........
    Quote Quote  
  5. Member DB83's Avatar
    Join Date
    Jul 2007
    Location
    United Kingdom
    Search Comp PM
    I know fook all about sub-titles but I do wonder if what you interpret as subs in the original video where actually part of the original film and not removable on the original disk.

    That being so, the programs have incorrectly interpretated some bytes which causes this odd behaviour - that particular line could be in a slightly different position to others.

    BTW it is clear that you do not own the original disk else you would not be messing around with a mkv. But if you do then rip it again in a more conventional manner.
    Quote Quote  
  6. Member Cornucopia's Avatar
    Join Date
    Oct 2001
    Location
    Deep in the Heart of Texas
    Search PM
    It's not just the platform that confounds and complicates things, it's also the coding: ASCII, ANSI, UTF-8, UTF-16, straight Unicode, etc. Some apps expect one kind and work with it internally yet accept many kinds, some only accept ONE kind and output that kind, and not all of them are the same. I've encountered this very same problem on more than one occasion and traced the root of the problem to this inconsistency.

    So you may need to do a little re-formatting with a good Text Editor first to "massage your data into compliance" with your intended app.

    Scott
    Quote Quote  
  7. Tried something like easySup instead of Txt2Sup?
    Pull! Bang! Darn!
    Quote Quote  
  8. Member
    Join Date
    Apr 2007
    Location
    United Kingdom
    Search Comp PM
    Originally Posted by El Heggunte View Post
    Drop Txt2Sup, or SVCD2DVD, or both.

    I've never used SVCD2DVD, but I do have used Txt2Sup, and I know that it suXXX.
    Very good. I see my attempt to divert such responses was ignored. Still, I'll bite.

    Can you be more constructive? For instance, why do you think Txt2Sup sucks? Anything specific that might relate to what I'm seeing? Any suggestions as to alternatives that don't suck?

    I have used SubtitleCreator but found it a little overpowered for what I needed, and getting correct subtitle timings from it for 29.97fps video required some manual tweaks because it automatically applies a conversion factor when you save SUP files for NTSC. I like to keep my workflow simple. It did eliminate the need for subtitle colour editing with IFOEdit which was nice, but overall it didn't give the simple, aesthetically pleasing and consistent results I'm getting from Txt2Sup.

    I've also tried AVS2DVD which is the most often recommended one-stop replacement for the effectively abandoned SVCD2DVD, but I find it outputs my NTSC DVDs at 30fps even when the source is 29.97. Makes for jerky playback on certain scenes, and requires even more manual tweaking for subtitle timings.

    Any more for any more? I guess I should know by now that every thread on an internet forum must at some point descend into a content-free advocacy war where everything "sux" or "rox" and there's nothing in between. It must be a rule or something. I don't even know why I try to pre-empt it.

    Still, moving on to the meaningful replies...

    Originally Posted by jman98 View Post
    I've seen bizarre, seemingly inexplicable subtitle problems caused by a subtitles file having invisible special characters in it. Editing a subtitle file in Linux or Mac and moving it to Windows or vice-versa can lead to this because of differences in end of line characters.
    Originally Posted by Cornucopia View Post
    It's not just the platform that confounds and complicates things, it's also the coding: ASCII, ANSI, UTF-8, UTF-16, straight Unicode, etc. Some apps expect one kind and work with it internally yet accept many kinds, some only accept ONE kind and output that kind, and not all of them are the same. I've encountered this very same problem on more than one occasion and traced the root of the problem to this inconsistency.
    I did consider line terminations (another reason I didn't get on with AVS2DVD was its seeming finickiness when it came to text formats) and noted that the dialogue in question was split over two lines. I thought the line break might be the key. But then an earlier two-line subtitle encoded without issue, as did several later ones. I did try starting with the .SRT in both UTF-8 (CR+LF) and UNIX ASCII (LF only) -- Metapad supports a surprising number of formats for a Windows program -- but that didn't help. If I don't get distracted by another problem I might get around to trying a few more formats but I suspect if it was a line termination problem one of those two would have either corrected it or made it worse.

    Originally Posted by racer-x View Post
    Change it to Budweiser and call it a day
    Sadly another character names the beer in the next exchange. It's not Bud

    Originally Posted by DB83 View Post
    BTW it is clear that you do not own the original disk else you would not be messing around with a mkv. But if you do then rip it again in a more conventional manner.
    I will own it in a few weeks when a certain box set that includes this source material gets released But if I'd waited until then I could have just loaned the disk to the person that I did this one for, instead of having to "obtain" a copy and burn it to DVD. In retrospect that might have been the easier solution, but then where's the fun in that?

    Originally Posted by fritzi93 View Post
    Tried something like easySup instead of Txt2Sup?
    I'd not heard of that one. Thanks, I'll give it a try the next time I'm attempting something like this.

    It looks as though this may be just another "one of those things" that comes as part and parcel of the complexity of video work. I was kind of hoping someone might have remembered seeing the exact same thing and chimed in with "I thought it was just me!" but I guess it was a long shot. This situation is so dependent upon a unique combination of software and settings -- and dialogue -- that this may be the first time it has ever manifest and it may never manifest again.

    Ah well. All part of the joy of computing.
    Quote Quote  
  9. I'm a Super Moderator johns0's Avatar
    Join Date
    Jun 2002
    Location
    canada
    Search Comp PM
    Sounds like you got the Edge of Tomorrow web release and want to block the chinese subs with a pgs sup.
    I think,therefore i am a hamster.
    Quote Quote  
Visit our sponsor! Try DVDFab and backup Blu-rays!