AviSynth rendered subtitles to BluRay SUP/PGS and BDN XML (v2.08)

[sneaker_ger]

Thanks for the info - sadly two of the documents linked in there don't exist anymore. I don't fully understand yet, but I hope I got the most important facts straight:

1.) Choosing 23.976, 29.97 (or 59.94) makes avs2bdnxml create the timecodes in the "drop"-way?
2.) Choosing 24 means it creates non-drop "23.976", choosing 30 means creating non-drop 29.97?
3.) There's currently no way to create 59.94 fps material the non-drop way?
4.) 25 and 50 are probably always created the non-drop way because of PAL? (Yet another reason why PAL is superior)

More questions/requests:
5.) is choosing 24 really creating perfect non-drop 23.976 timecodes or will it go out of sync on long movies? (same question for 30)
6.) I find the usage of this really irritating and most programs seem to expect non-drop timecodes anyway so I suggest you add another switch for "drop" or "non-drop" and make non-drop the default. That's more user friendly as it does not let every new user of this program run into the same problem.

[ps auxw]

Originally Posted by sneaker_ger

Another problem:

<Event Forced="False" InTC="00:16:30:13" OutTC="00:16:33:23">
<Graphic Width="1280" Height="720" X="0" Y="0">00023774.png</Graphic>
</Event>
<Event Forced="False" InTC="00:16:33:18" OutTC="00:16:35:04">
<Graphic Width="1280" Height="720" X="0" Y="0">00023851.png</Graphic>

This really shouldn't happen, so it's a bug. I'll go look for it.

Originally Posted by sneaker_ger

1.) Choosing 23.976, 29.97 (or 59.94) makes avs2bdnxml create the timecodes in the "drop"-way?
2.) Choosing 24 means it creates non-drop "23.976", choosing 30 means creating non-drop 29.97?
3.) There's currently no way to create 59.94 fps material the non-drop way?
4.) 25 and 50 are probably always created the non-drop way because of PAL? (Yet another reason why PAL is superior)
5.) is choosing 24 really creating perfect non-drop 23.976 timecodes or will it go out of sync on long movies? (same question for 30)
6.) I find the usage of this really irritating and most programs seem to expect non-drop timecodes anyway so I suggest you add another switch for "drop" or "non-drop" and make non-drop the default. That's more user friendly as it does not let every new user of this program run into the same problem.

1) Yes.
2) Yes, for 30 the correct value of 29.97 is written to the XML too.
3) You should be able to give a frame rate of 60 and edit the XML. There is no error checking there, yet.
4) To my knowledge, this is correct.
5) The created timecodes should be correct.
6) It is quite irritating! I will definitely make the usage more clear in the next version (23.976, 29.97 and 59.94 will be non-drop by default, with 23.976d etc. for the drop version). I would have done so before, but I wasn't aware of the problem. That's the fun thing about A/V processing, there's always a surprise left.

[sneaker_ger]

Thanks. Exactly what I wanted to hear.

[ps auxw]

I just finished the new version of avs2bdnxml. The overlapping timecode issue should be fixed. I optimized the code, too. Sadly, the optimization didn't help as much as I had hoped, since the majority of time (4/5 or so, in my 720p test) is spent in AviSynth/VSFilter. Non-drop timecodes are the default now, editing the XML file to correct the framerate should be no longer necessary.

[sneaker_ger]

Thx, seems to work just fine.

But I just noticed: Aren't you and I mixing non-drop and drop? As it is now, isn't "drop" the default, while "23.976d" is in fact "non-drop"?

[ps auxw]

No, I think everything is correct. In the non-drop time code thread the example given for a non-drop time code of a certain frame ("For example, 02:34:17:12 (non-drop-frame) is 277722 frames") matches the way it is now calculated in avs2bdnxml, and it seems to be correct from a theoretical point of view too.

[sneaker_ger]

Yet another problem:

Sometimes the subtitle timing is 1 frame off. I'm not sure if it's the fault of avs2bdnxml or the fault of BDSup2Sub/BDSubEdit.

Sample

[sneaker_ger]

Originally Posted by ps auxw

No, I think everything is correct. In the non-drop time code thread the example given for a non-drop time code of a certain frame ("For example, 02:34:17:12 (non-drop-frame) is 277722 frames") matches the way it is now calculated in avs2bdnxml, and it seems to be correct from a theoretical point of view too.

You're right - stupid me.

[ps auxw]

Originally Posted by sneaker_ger

Sometimes the subtitle timing is 1 frame off. I'm not sure if it's the fault of avs2bdnxml or the fault of BDSup2Sub/BDSubEdit.

Thanks for reporting. Could you tell me how you checked that the subtitle is 1 frame off? Also, is shifted or is just the beginning or end wrong, and in which direction is it off? The time code in the XML looks correct, and I'm not sure I am looking at the SUP files in the correct way.

[sneaker_ger]

The easiest way is to use the following AviSynth-Script and skip through it frame by frame with VirtualDub:

BlankClip(240,1280,720,"YV12",fps=24000,fps_denominator=1001)
SupTitle("color_bdsup2sub.sup",false)
Crop(0,100,0,0)
AddBorders(0,0,0,100)
TextSub("color.ass")

Besides vsfilter you'll also need the SupTitle plugin.

Sometimes the subtitles appear 1 frame too late, sometimes they disappear 1 frame too late and sometimes both happens. In this specific sample it appears too late. I also created a .sup using PunkGraphicStream and the result was correct, so it's probably not an issue of SupTitle.

[sneaker_ger]

After thinking about it, it's probably an error in BDSup2Sub and BDSubEdit. The xml file clearly states that the subtitle should be displayed at "00:00:01:00", which is frame number 24 (or the 25th frame) and the resulting .sup is one frame too late. Please have a look at it anyway since I want to make sure it's really an error in both of the programs before contacting them.

Another thing - totally unrelated to my problem - I noticed is that even when using "23.976d" the "drop" parameter in the xml is "false".

[ps auxw]

Originally Posted by sneaker_ger

The easiest way is to use the following AviSynth-Script and skip through it frame by frame with VirtualDub:

BlankClip(240,1280,720,"YV12",fps=24000,fps_denominator=1001)
SupTitle("color_bdsup2sub.sup",false)
Crop(0,100,0,0)
AddBorders(0,0,0,100)
TextSub("color.ass")

Besides vsfilter you'll also need the SupTitle plugin.

Thanks, this helps.

Originally Posted by sneaker_ger

After thinking about it, it's probably an error in BDSup2Sub and BDSubEdit. The xml file clearly states that the subtitle should be displayed at "00:00:01:00", which is frame number 24 (or the 25th frame) and the resulting .sup is one frame too late. Please have a look at it anyway since I want to make sure it's really an error in both of the programs before contacting them.

I have looked over the code once more and also tried making a SUP with PGS. After converting that SUP to BDN XML with BDSup2Sub, it matched the output of avs2bdnxml, so that really should be correct.

Another thing - totally unrelated to my problem - I noticed is that even when using "23.976d" the "drop" parameter in the xml is "false".

Thanks, this will be fixed in the next version. I forgot to add code to adjust that attribute.

[ps auxw]

New version: I fixed the DropFrame bug and made detection of empty and different frames a bit more robust. Detection of SSE2 is now automatic.

[deank]

Thanks for this handy application! I wonder why I didn't see it earlier!

I have a small question. If for some reason the application executes exit() I get a crash window + :

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

For example when there is no data processed as in:

Progress: 100/100 - Lines: 0 - Done
No events detected. Refusing to write XML file.

Is it possible to make avs2bdn exit with return 0 or at least in a fashion that won't make it crash?

Thank you once again!

Dean

[ps auxw]

Originally Posted by deank

Thanks for this handy application! I wonder why I didn't see it earlier!

I'm glad to hear you find it useful.

Is it possible to make avs2bdn exit with return 0 or at least in a fashion that won't make it crash?

Here's quick fix. It should get rid of this problem.

[hamletiii]

Just reminds me that this program (ver1.6) will not output anything if the subtitle line contains empty space only. I just need some dummy transparent subtitle tracks the other day.

[deank]

Originally Posted by ps auxw

I'm glad to hear you find it useful.
Here's quick fix. It should get rid of this problem.

Thanks. I added 'advanced subtitle options' in multiAVCHD thanks to your program in combination with bdsup2sub.

I did a lot of tests yesterday and I found it a bit slow and I remember you saying that most of the time is spent by avisynth, so here is what I did:

Testing scenario:

* video with resolution 1920x1080 @ 23.976fps
* duration ~1hr 17mins (~110 000 frames)
* SRT subtitles with 1000 lines
* .styles file for VSFilter (no affect on speed)
* .avs script, using full frame (1920, 1080 parameters)

* avs2bdnxml.exe run time: 28 mins
* bdsup2sub.jar run time: 8 mins
* Total time for processing: 36 mins

---------------------

Now, I decided that there is no need for avisynth to create a full frame 1920x1080, since subtitles usually use about 30% of the screen. Having this in mind and expecting quality input text subtitles (since I'm a translator and create subtitles), which won't have more than 2 or 3 lines of text I decided to reduce the frame sizes, processed by all applications involved (avisynth+avs2bdnxml+bdsup2sub):

Before I start I am aware of font size, bottom offset and video resolution (of course), so I set a frame height to be not 1080 but 3.2*(font_type) mod 4. For example with 65pt font you get a frame of 1920x208 pixels.

* video with resolution 1920x1080 @ 23.976fps
* duration ~1hr 17mins (~110 000 frames)
* SRT subtitles with 1000 lines
* .styles file for VSFilter (using PlayResY: 208)
* .avs script, using new frame (1920, 208 parameters)

* avs2bdnxml.exe run time: 7 mins
* bdsup2sub.jar run time: 2 mins
* Total time for processing: 9 mins

A small modification is needed in the .xml file before it is passed to bdsup2sub:

All Y offsets (Y=0) are changed to Y= (original_frame_height - new_frame_height - bottom_offset), as in the example (using bottom offset of 32pixels), Y=1080 - 208 - 32 = 840.

Also the "VideoFormat" option in the <Format/> section is set with the proper (original) resolution (i.e. "1080p") - I added the 'p' because I saw that bdsup2sub uses it, instead of using the plain numeric value. I guess "1080" is okay, too.

I implemented these steps in multiAVCHD and now producing the .sup/PGS from SSA, ASS, SRT and microDVD sub text subtitles takes 5 to 10 times less, depending on the resolution.

And thanks again for your contribution!

Dean

[sneaker_ger]

That's a nice speed up but you should probably make it optional since ASS is often used for translations of signs for example. (Or even simpler: translations of tv speakers in the background are often put at the top of the screen) That would destroy the subtitles.

If you want more speed you may want to try AssRender as a vsfilter alternative or PunkGraphicStream. They are not as powerful as vsfilter+avs2bdnxml and the latter has a serious problem with big subtitles at the moment but I expect them to get better.

[deank]

Yes, there is now an option for 'full-frame' generation. Thanks for the suggestion

[ps auxw]

Originally Posted by hamletiii

Just reminds me that this program (ver1.6) will not output anything if the subtitle line contains empty space only. I just need some dummy transparent subtitle tracks the other day.

This is due to the way it works. avs2bdnxml only looks at the frames. If a frame is completely transparent/empty, it will assume that there is no subtitle in that frame. You could use a dummy line and replace all references to PNGs with a single one to a transparent PNG though.

Originally Posted by deank

* Total time for processing: 36 mins
[...]
* Total time for processing: 9 mins

Nice idea. Once I add real commandline argument parsing, I'll add a way to set X and Y offsets, so the XML can be generated correctly with smaller frame sizes.