February 27, 2021, 08:54:20 AM

News:

--


.SRT to .SSA parsing bug?

Started by NovicED, December 24, 2018, 01:11:11 AM

Previous topic - Next topic

NovicED

Using Avidemux 2.7.1-181128

Tried to load existing .SRT subtitle file only to find it created an empty .SSA file.
Traced the problem to the timestamp format which was:

##:##:##.###

The SSA converter in Avidemux appears to only accept:

##:##:##,###

To verify I manually edited the first few entries and those then worked.

The player in Win10 recognizes either time format and properly
Avidemux should too.

NovicED

I was able to edit the SRT file but now there is a greater problem.  When trying to burn the subtitles
into the video, the text is delayed by about 4 seconds.  This shows up in both preview mode and
saved video.  Is this another bug - or something technical Avidemux has difficulty achieving?

 

eumagga0x2a

QuoteThe SSA converter in Avidemux appears to only accept:

##:##:##,###

Yes, the correct decimal separator for timestamps in .srt is a comma, so this is strictly speaking not a bug but adherence to specifications.

QuoteWhen trying to burn the subtitles into the video, the text is delayed by about 4 seconds.  This shows up in both preview mode and saved video.

Did you verify the subtitle file with Aegisub? What is the presentation timestamp (PTS) of the first frame of this particular video in Avidemux?

NovicED

December 28, 2018, 07:00:24 AM #3 Last Edit: December 28, 2018, 07:31:08 AM by eumagga0x2a
Quote from: eumagga0x2a on December 24, 2018, 10:11:46 AM
QuoteThe SSA converter in Avidemux appears to only accept:

##:##:##,###

Yes, the correct decimal separator for timestamps in .srt is a comma, so this is strictly speaking not a bug but adherence to specifications.

Now that other sub editors (apparently) and players are accepting either '.'  or ',' it's something tools
like Avidemux can't really afford ignore.  I've since d/loaded Aegisub and notice it doesn't like '.' either.

Quote
QuoteWhen trying to burn the subtitles into the video, the text is delayed by about 4 seconds.  This shows up in both preview mode and saved video.

Did you verify the subtitle file with Aegisub? What is the presentation timestamp (PTS) of the first frame of this particular video in Avidemux?

Aegisub shows no obvious problem (after I'd converted the '.' the ',') other than CPS warnings.

How do I find the PTS and how might this affect the subttl sync?  Sorry but I'm new to video editing.

eumagga0x2a

I've fixed quote tags for better legibility.

Quote from: NovicED on December 28, 2018, 07:00:24 AM
How do I find the PTS and how might this affect the subttl sync?

Avidemux uses unsigned values to store timestamps (both decode and presentation) of video frames. If a video contains B-frames (frames which require more than a single one previously decoded frame for being decoded, with at least one of these reference frames displayed later), presentation times of all frames have to be delayed as timestamps can't go negative.

Another reason for differing timestamps might be audio shift (advancing audio WRT video = delaying video). This means, whoever created the original .srt, might have used a tool which doesn't agree with Avidemux about timing in the video. Usually this disagreement is very small, but sometimes it is not.

The PTS of the first frame is the time shown in the bottom left corner of Avidemux right when you load a video.

NovicED

Sorry for the delay replying and thanks for the explanation.  Checked the videos
I'm using for testing and the PTS shown varies from 0 to under 1 second.

I've created my own SRT file for testing:

1
00:00:02,500 --> 00:00:05,000
Subtitle 1:  2.500 to 5.000 seconds.

2
00:00:10,000 --> 00:00:15,000
Subtitle 2:  10.000 to 15.000 seconds.

3
00:00:20,500 --> 00:00:25,000
Subtitle 3:  20.500 to 25.000 seconds.

4
00:00:30,000 --> 00:00:35,000
Subtitle 4:  30.000 to 35.000 seconds.

Avidemux converts all the SRT entries to SSA format:

[Events]
Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
Dialogue: 0,0:00:02.500,0:00:05.000,Default,,0000,0000,0000,,Subtitle 1:  2.500 to 5.000 seconds.
Dialogue: 0,0:00:10.000,0:00:15.000,Default,,0000,0000,0000,,Subtitle 2:  10.000 to 15.000 seconds.
Dialogue: 0,0:00:20.500,0:00:25.000,Default,,0000,0000,0000,,Subtitle 3:  20.500 to 25.000 seconds.
Dialogue: 0,0:00:30.000,0:00:35.000,Default,,0000,0000,0000,,Subtitle 4:  30.000 to 35.000 seconds.

However when I 'preview' the output I see only subtitles 2 & 4 (at the correct timestamp).  Subtitles
not beginning on an integral number of seconds are not processed at all.  Tried it on two videos with
the same result.

p.s. I ended up hard coding the subtitles by capturing Win10 videoplayer output.  Nevertheless I'd
still like to sort out what is the issue with Avidemux' handling of subtitles.


eumagga0x2a

The supported time format is xx:xx:xx.xx, NOT xx:xx:xx.xxx. WFM with unflawed time format, see attached .ssa file.

NovicED

Quote from: eumagga0x2a on January 06, 2019, 01:44:45 PM
The supported time format is xx:xx:xx.xx, NOT xx:xx:xx.xxx. WFM with unflawed time format, see attached .ssa file.

That may explain the 'delay' I was initially getting i.e. Avidemux interpreting the
illegal numeric string in the SSA file and possibly producing a different time.

Given SRT format specifies 3 decimal digits, Avidemux SRT/SSA converter should
properly convert it to 2 decimal SSA format - but doesn't.  Strange the bug hasn't
been noticed before this and squashed.

I now have enough info to proceed.  Thanks for pinning down the problem.