BDSup2Sub - convert and tweak bitmap subtitle streams (VobSub,BD-SUP,BDN XML,HD-SUP)

I tried it with --move-x origin and various offset values and it's moving it correctly (even with the -10 and 10). I reloaded the output of the CLI in the GUI and the position of decoded subtitles from the CLI output matches the position of when doing the move within the GUI. I've even done a binary comparison between the outputs of doing the origin move from both GUI and CLI and they are identical. And doing -10 and 10 from the CLI does not give me the same output as I again did a binary comparison on that.

And just to make sure it wasn't just confirmation bias using BDSup2Sub++, I opened up the offset -10 and offset 10 CLI output in SubtitleCreator and the horizontal position was offset as it was supposed to be.

[r0lZ]

I think I've found why it did not work here. I did my tests with very high offsets (-800 and +800) to verify if the subs are not moved out of the "screen", and with that values, the position is not changed at all. However, with more decent values such as -10 and +10, it works fine. So, IMO, there is a little bug. The subs should be moved as far as possible without going out of the screen when the offset value is too low or high. Instead, it does nothing, and no warning is printed. Not a big problem, but perhaps the bug may happen even with relatively small values such as -100, if the subtitle is very large. Not to worry, but IMO, it's something to fix (later if you wish).

BTW, if you sets a limit, don't forget that there is a little margin (IIRC 2 or 4 pixels) where the subpic cannot de located (for the DVDs). I don't know if the same limitation applies to BDs. Anyway, it doesn't make much sense to stick a subtitle to the border, so IMO, a minimal margin of, say, 10 pixels would be perfect.

No, it's already limiting the range if you do a huge value like that. There's some other issue causing what you see that I'm trying to track down.

[r0lZ]

Can you reproduce it?

r0lz I'm refreshing the 1.0.0 now that I know the error. Also, I've created a new thread to discuss BDSup2Sub++ in so we can leave this for the original Java version now.

[FulciLives]

I am re-encoding a 1080p Blu-Ray to 720p and it has subtitles so I used this (awesome) program to convert them to IDX/SUB format. However I tried leaving the subs at 1080p as well as resizing them to 720p and they seem to look basically the same when using VLC Media Player. So should I just leave them at 1080p (I'm watching on a 1080p monitor) or is it more proper to resize to 720p instead?

Any pitfalls over doing it one way (no resizing) vs the other (resizing)?

[LeXXuz]

I never resize picture subtitles. In most cases the downsized version just looks poor, even from 1080p to 720p, not to mention downscaling to SD resolutions.

Until now, I never had problems with subs in 1080p and video <1080p. Neither on PC or media players like TViX, WDTV etc. They play just fine.

So my advice: forget about resizing unless you have some exotic hardware for playback.

[FulciLives]

Originally Posted by LeXXuz

I never resize picture subtitles. In most cases the downsized version just looks poor, even from 1080p to 720p, not to mention downscaling to SD resolutions.

Until now, I never had problems with subs in 1080p and video <1080p. Neither on PC or media players like TViX, WDTV etc. They play just fine.

So my advice: forget about resizing unless you have some exotic hardware for playback.

Thanks!

Also good to know this will work with the WDTV because while I don't have one I have been thinking of getting one.

[DoctorM]

Originally Posted by FulciLives

I am re-encoding a 1080p Blu-Ray to 720p and it has subtitles so I used this (awesome) program to convert them to IDX/SUB format. However I tried leaving the subs at 1080p as well as resizing them to 720p and they seem to look basically the same when using VLC Media Player. So should I just leave them at 1080p (I'm watching on a 1080p monitor) or is it more proper to resize to 720p instead?

Any pitfalls over doing it one way (no resizing) vs the other (resizing)?

VLC is one of the few players that resize the subtitles on playback to fit the window. (I believe this has something to do with the order in which it renders the subtitles with the video on playback as opposed to overlaying the titles after rendering.) (It's also why VLC can't add black borders and render the subtitles into that area.)

Many other players will play a 720p video with 1080p subtitles in a manner that the titles will be malpositioned or even outside of the player's viewing area (basically at full 1080 resolution). DirectVobSub & MPC-HT have this problem.

I've seen many bdrips (and it seems to be fairly common) with this combination. There'd be nothing wrong with this if the development of subtitle filters kept apace.

@LeXXuz - Maybe you should try a different resize method.

[rakuen.now]

I've been trying to post this for several days now. Okay, it seems most of you use BDSup2Sub mainly to convert blu-ray subtitles for DVD or MKV. You might remember mjuhasz a few months ago updated this to prevent flashing, or disappearing subs when played back with XBMC. He only fixed it, supposedly (I didn't test), for the DVD options, but not .sup(BD). I only use BDSup2Sub to move my blu-ray subtitles vertically so that they don't go into the black bars, since I have an anamorphic setup.

So I downloaded a Java IDE and a hex editor, and started my reintroduction to Java since college freshman year when I flunked. Luckily, it wasn't that hard to follow, though I'm still not too confident in my coding, so hopefully if someone has the same problem I did, maybe you could test this more extensively with me before whoever commits these changes to the official version -- if they do.

What you do is in the file 'SupBD.java', under the 'createSupFrame()' method, starting at line 606, whenever there is a DTS header as such:
setDWord(packetHeader, 6, dts);

Replace that with this:
setDWord(packetHeader, 6, 0);

And then in the last 'END' packet, on line 745, where it says:
setDWord(packetHeader, 2, dts);

Replace that with this:
setDWord(packetHeader, 2, timeStamp);

And the result should get you very close to what tsMuxer outputs. The timing will still be off by some milliseconds, but you won't notice any difference. I've tested this with a few titles (e.g. House of Flying Daggers, V For Vendetta, etc.) where the source subtitles go into the black bars area, and they seem to work. I tried submitting this to one of the gitHubs, but I have no idea how that works. But anyways, here it is. It doesn't look like 0xdeadbeef or mjuhasz is active, so maybe someone familiar with Java could try compiling it and testing it out. Thank you.

[mjuhasz]

Originally Posted by FulciLives

Thanks!

Also good to know this will work with the WDTV because while I don't have one I have been thinking of getting one.

Just make sure you download the special version for WDTV: https://github.com/downloads/mjuhasz/BDSup2Sub/BDSup2Sub-wdtv.jar

I explained in a blog post why.

[r0lZ]

IIRC, that palette bug is also fixed in the latest ++ version.

[mjuhasz]

Originally Posted by rakuen.now

I've been trying to post this for several days now. Okay, it seems most of you use BDSup2Sub mainly to convert blu-ray subtitles for DVD or MKV. You might remember mjuhasz a few months ago updated this to prevent flashing, or disappearing subs when played back with XBMC. He only fixed it, supposedly (I didn't test), for the DVD options, but not .sup(BD). I only use BDSup2Sub to move my blu-ray subtitles vertically so that they don't go into the black bars, since I have an anamorphic setup.

So I downloaded a Java IDE and a hex editor, and started my reintroduction to Java since college freshman year when I flunked. Luckily, it wasn't that hard to follow, though I'm still not too confident in my coding, so hopefully if someone has the same problem I did, maybe you could test this more extensively with me before whoever commits these changes to the official version -- if they do.

What you do is in the file 'SupBD.java', under the 'createSupFrame()' method, starting at line 606, whenever there is a DTS header as such:
setDWord(packetHeader, 6, dts);

Replace that with this:
setDWord(packetHeader, 6, 0);

And then in the last 'END' packet, on line 745, where it says:
setDWord(packetHeader, 2, dts);

Replace that with this:
setDWord(packetHeader, 2, timeStamp);

And the result should get you very close to what tsMuxer outputs. The timing will still be off by some milliseconds, but you won't notice any difference. I've tested this with a few titles (e.g. House of Flying Daggers, V For Vendetta, etc.) where the source subtitles go into the black bars area, and they seem to work. I tried submitting this to one of the gitHubs, but I have no idea how that works. But anyways, here it is. It doesn't look like 0xdeadbeef or mjuhasz is active, so maybe someone familiar with Java could try compiling it and testing it out. Thank you.

Thank you for looking into this. 0xdeadbeef is not maintaining the code anymore but I am. While I may seem to be inactive I am still maintaining the code and planning to release a new version once I'm done with testing. You are always welcome to download the development snapshot version and report issues on GitHub. Check the closed issues for changes between the latest stable and the snapshot.

I created an issue for what you described on GitHub. I am on vacation/business trip in the upcoming weeks so some patience will be needed until I get to it (unless someone fixes it and sends me a pull request). Thanks for the pointers!

[Chetwood]

So are you and Sassbot pooling your recsources or are we still seeing two different versions with more or less identical features?

Well I didn't really create the version to compete with mjuhasz or take users. I just did it to get back into C++ programming and figured someone else might find use in it. If mjuhasz wants to combine resources that's fine with me.

[Chetwood]

Whatever you guys decided on, if fine by me. I was just wondering if you had implented the WDTV fix as well.

I have done so on the local branch I'm working on. It's not pushed to github yet and won't be for a while still. There's a rather large amount of re-architecting I'm finishing up first.

[Pawpcorn]

Hi; has anyone come up with a program or method to merge TWO idx/sub subtitle files together?
Example: TWO different language idx/sub subtitle files, where I've re-positioned them both, so as not to appear in the same location on screen.
I'd like to merge them into ONE idx/sub file, to be able to turn BOTH on, or BOTH off, with any DVD player / program.
Thanks!!!
P.S. using .srt format files won't work in this case, since I don't have OCR software for THAI language

[Chetwood]

VobSub Shuffle can merge several languages into one VobSub, if that's what you mean.