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

[r0lZ]

Originally Posted by Scorpius666

It is exactly that.

If you select the "Change Frame" option then you will need to enter a source frame rate and the program will translate the times for you. If you don't, the Target FPS is still used only for the formats that will use it.

It's almost true. The Target FPS is used anyway, regardless of the format of the input or output stream, but the stream is not stretched or shrunk. The only change is that the output timings are rounded so that they will coincide exactly with the frames of a movie at the specified target FPS. In other words, if you save the stream, it will still be more or less compatible with the original movie, but with imprecise time codes. And it will NOT be equal to the original. The difference might be negligible, but it exists. For example, a subtitle at 01:37:20.418 will be (slightly) moved to 01:37:20.400. A difference of 18ms is not much, but it exists. (You can see the rounded timecodes in the lower pane of BDSup2Sub.) It's why I suggest, when the stream is loaded, to set by default the same Target FPS than the source FPS (detected usually correctly, even when a format without FPS is loaded). That way, by default, the timings will never be changed. Plus, for the formats using the FPS (like XML/PNG), the correct value will be included. Currently, you have to pay attention to the Target FPS, without any good reason. Why keep this obligation if it can be avoided simply?

Originally Posted by Scorpius666

But if you export to IDX/SUB for example that is totally ignored since it is not needed.

No, it's important to have the correct frame rate stored in the XML, because if you save it with, say, 25fps, when you will reload it, the program will wrongly assume that the FPS Source is 25. So, the current behaviour is misleading, unless you fix manually the little discrepancy of the wrong FPS Target in the first window.

Originally Posted by Scorpius666

The question remains: Why is there a frame rate setting in the first place for formats that have absolute time? I'm pretty sure if you delete the frame rate line from the XML file it will always work. I would test it, but that format is so messy creating thousands of files that I really want to stay away from it.

IMO, it's an excellent thing to tag the stream with the frame rate. I agree that that should not influence the absolute times (except for the rounding to exact frame starts), but don't forget that a subtitle stream has no interest at all without a movie, and the movie has a specific frame rate. The timings for a PAL movie are totally different than for the same movie in NTSC, and again different for a film at 24fps. When the frame rate is included in the stream, you know for what target frame rate the stream has been designed. It's an extremely important information. Most sync problems peoples are experiencing with downloaded subtitles come from the absence of the frame rate in the SRT format. At least, with XML/PNG, that problem is avoided... if the frame rate stored in the XML is correct, of course.

Originally Posted by Scorpius666

Also, the ONLY format that BDSup2Sub that needs a frame rate is XML/PNG. What I would do is test an XML file without the frame rate option, and if it works, then delete the output of that line in BDSup2Sub. I'm sure it will work!!

Yes, it will probably work, but please don't do that. Despite what you think about the XML/PNG format, it's certainly the more professional format supported by BDSup2Sub. It is extremely interesting to modify some things that you can't do with the GUI. I use it in BD3D2MK3D, for example, to convert the subtitles to 3D Half-SBS or Half-T&B. The presence of the frame rate tag in the XML is really useful to verify that the stream is compatible with the movie. Note also that XML/PNG is the format necessary for many authoring programs, like Sonic or Scenarist. You cannot simply say that it is useless because you don't like it.

However, I agree that it saves a lot of PNG files. And currently, it doesn't force the user to create a new directory to keep all these files together. Perhaps you could add (as an option?) the automatic creation of a sub-directory when the XML is saved? That way, you won't need to pay attention to where you save it. It's just a suggestion...

Originally Posted by Scorpius666

EDIT: Reading the wiki at https://github.com/mjuhasz/BDSup2Sub...ported-Formats seems like not only the frame rate value is needed, but the values are not absolute values but things that are really weird, like the time codes are related an integer frame rate (24 instead of 23.976). I would really stay away from this format.

Oh, yes, I hate also the problem of the drop or non-drop frames with all NTSC frame rates, but it's an inheritance of the crappy NTSC Video format, and we have to live with that. (And, BTW, I don't understand at all why the US has forced the rest of the world to use the infamous 23.976 frame rate for HD and 3D movies, instead of the film standard of 24 fps, much more simple and without the drop frame nightmare! After all, we are in the 21st century, and keeping obscure limitations inherited from the frequency of the US AC at 110v is completely hallucinating!)

Also, if currently, most (if not all, I don't know) timings internal to video, audio and subtitles streams are expressed in absolute and precise times (for their real frame rate), it's not at all the same thing in production, where precise time codes are not handy. They HAVE to be rounded at 24 fps, because we are human beings, and not machines. The fact that XML/PNG permits to use drop or non-drop times is complex, but that means only that that format has been correctly designed with video production and human beings in mind. It's one of its obvious advantages over the other formats. I haven't tried to change the DropFrame="False" option in the XML, but I suppose that it is there to support both drop and non-drop frames timecodes. If it's the case, it should be possible to use exactly the same time codes in the XML than with the other formats.

Of course, when an XML/PNG file is saved at 24 or 25 fps (or any integer FPS), the drop frames problem is totally absent, and XML/PNG can be used very simply.