Modifying textsub to allow frames in place of ms

[getfresh]

Has anyone else ever thought that it might be useful having textsub modified to allow for smpte based timecode in ssa/ass files. Like instead of hh:mm:ss.ms you can use hh:mm:ss.ff. FF meaning frame frame of course. I think that this would be a much more logical way of entering times or transition durations. I know there are many different formats of frame rates now, but if a video editor can detect the framerate and still play the video back properly why can't that also be true for textsub?

[Nicholi]

Originally Posted by getfresh

I know there are many different formats of frame rates now, but if a video editor can detect the framerate and still play the video back properly why can't that also be true for textsub?

Because it's a bad idea. Need more be said? Not so simple to just implement because "video can be played thus textsub knows what to do".

Also it only goes down to centiseconds, not milliseconds. Which is also another equally pointless idea.

[jfs]

Ie. you want support for textual format SMPTE timestamps. What about weird framerates such as 30/1.001? Should it be stored with the madness called SMPTE dropframe? Please don't. And it still won't cover VFR in a sensible way.
One thing that could possibly, and only possibly, make sense, would be storing only a frame number for time, ie. not second+subframe but only frame. Unfortunately that would only work in VDub and Avisynth because DirectShow doesn't have a well defined notion of frame numbers. (And how would dropped frames in VfW be represented either way? Would they count?)

As long as you use sensible framerates (ie. no "120 fps" crap) and stable video sources (that can reliably seek to the same frame every time given the same timestamp) there's nothing wrong with centisecond precision, it can identify any frame in the video.

Now one thing that *could* possibly be interesting and maybe even reasonable to implement in VSFilter/TextSub would be to read arbitrary-precision timestamps, ie. allow h:mm:ss.uuuuuu if anyone wanted, but really just reading as many decimals as needed after the decimal point. I'm not sure if I'd want to hack that in though.

[getfresh]

Dropframe isn't rocket science. You are just dropping one frame every time you cross a 10th second. Yeah there is the VFR issue, but but the fact VFR was created means that something can be made to sync with it.

And Nicholi, I understand it isn't a simple thing. Also the professional media industry doesn't think timecode is such a bad idea. My main hope is to be able to eventually be able to load scripts in programs like finalcut while sync protools up as well.

I don't get what the "omg don't do it" is about. It's not like doing it will hurt the current version or cause a hard time for anyone who doesn't want to try it.

[jfs]

Here's some reasons to leave the ASS format and VSFilter alone and go build something new instead:
1. ASS is already over-hacked with various more or less compatible extensions. Better create something new instead.
2. VSFilter is (apparently) no longer being maintained by its original author.
3. VSFilter source code is horribly documented, mad spaghetti, buggy to boot and almost impossible to work with.
4. Several projects already exist to create something new to fix all the shortcomings.

We (Aegisub+asa) have been drafting up a new format "AS5" (that's the number five last) that fixes a lot of the inconsistencies in ASS, simplifies it for editing and rendering while keeping the good parts, and adds a whole lot of new things. It's still a draft, it can still be modified and extended.
Arbitrary precision timecodes is one of the things I have suggested but I couldn't get support for. I still think it can be a good idea if done right. Hacking it into VSFilter/ASS is not doing it right. Yes I realise I'm contradicting what I said in my earlier post now. I still think pure timestamp (h:mm:ss.cc) is a better idea for storing subtitles in general even if it means things that should be timed to specific video frames might not be timed in the most optimal way. Supporting more or less weird timecode formats is still worth doing however.

(If your reason for supporting SMPTE timecode is exporting to DVD authoring software and similar consider using an application to convert the subtitles to somehting more sensible beforehand. Aegisub 2 can also export to Adobe Premiere timed text format.)

[getfresh]

Well I agree with you that if it is easier to just start form scratch so be it. And yeah I know about the later VSFilter language issues. The biggest issue is with VDUB it's self. The language it is coded in was as I'm sure you know, a college project by the creator. textsub had to be coded in that ~_~.

How about back tracking to ssa 4.0 or seeing how incomplete 5.0 is. I'd dare to wager that ssa's formatting + engine, is a much cleaner source and starting point. From what I can gather most of the guts for all the .ass commands are there already in 4.0 but the issue was that the level of control you had over these functions was limited and the original "hack" was just to add more controls to functions. I could be wrong though.

anyways if you want 5.0beta to pick apart tell me and I'll go digging for it.

[jfs]

TextSub/VSFilter has very little heritage from VirtualDub. I believe VirtualDub itself is generally well designed etc. but that's not really relevant here. Avery Lee is usually regarded as a very talented developer.
TextSub inherits just one thing from Avery Lee and that's the rasterisation engine from his old Subtitler VDub plugin, that handled SSA2 and SSA4 files. (Maybe also SSA3, not sure.)
Everything else in TextSub is written from scratch, including the parsing and layout engines in it.

Furthermore, neither Subtitler nor TextSub share any source code with Substation Alpha. (Subtitler and TextSub are written in C++, SSA in Visual Basic.) The Substation Alpha source code is not open either.
I haven't examined it thoroughly, but the Subtitler source code seems quite well organised and readable, but it would still be a bad starting point for something new, because the layout requirements of ASS, not to mention an even more advanced format, would not fit well into its framework.
(I also have the SSA5 Preview 1 version myself, I didn't see any interesting changes in it however.)

No, there's already several very well progressing projects to implement new ASS renderers, which manage to be much faster and better written than VSFilter is. The real contestants are asa, libass and the Perian subtitle renderer. (Latter is Mac only.)

[getfresh]

sorry I was thinking of Sylia the script lang he had. And I didn't mess with v5 of ssa very much, just enough to crash it 5-6 times shortly after it was sent out for beta, and then you know what happened after making beta testing it further pointless.

[pichu]

Originally Posted by jfs

As long as you use sensible framerates (ie. no "120 fps" crap) and stable video sources (that can reliably seek to the same frame every time given the same timestamp) there's nothing wrong with centisecond precision, it can identify any frame in the video.

umm i think u can still do 1/120fps or more fps in ass... use \t with standard timings since it's milliseconds. Actually that reminds me, \t is the only way to time karaoke that has faster than \k2 timings (when there are 40 syllables in a line) since you'll get truncation errors.

Dialogue: 0,0:00:00.00,0:00:05.00,Default,0000,0000,0000,,{\frx90\t(83,83,\frx0)}This might work

ass already has flaws; I think it's better to start with a new format than to 'improvise' old format.

AFX uses time-based frames (base-frame # actually, i.e. 12b24 instead of 0.5s) though...