Small difference in subtitles timing depending on how they are demuxed

eac3to forked from madshi eac3to 3.36
Post Reply
DAE avatar
HPotter
Posts: 38
Joined: Thu Jul 29, 2021 9:54 am

Small difference in subtitles timing depending on how they are demuxed

Post by HPotter »

Found out curious thing, it's not really point here just curious.

Uploaded here subs made by 2 methods: https://easyupload.io/lln0he pass: Curly
.sup files the same as before, and OCR'ed first.
.sup those made by playlist method, _NEW.sup made by .m2ts files directly.

And look on timing for fin.srt vs fin_NEW.srt, for example, on 81, 83, 87, 89, 90, 720, 725 etc lines.
There is difference between timing for 00:00:00,001

And I think _NEW made by .m2ts files directly more correct as whole numbers like .250, .000, 500, 125 etc not .251, .001, 501, 126 etc like for playlist output.
DAE avatar
HPotter
Posts: 38
Joined: Thu Jul 29, 2021 9:54 am

Small difference in subtitles timing depending on how they are demuxed

Post by HPotter »

As we're going with new topic, it's going from here:
https://rationalqm.us/board/viewtopic.php?f=18&t=1297
So, the disk, the subs, the playlist, .m2ts files all the same as before, just after last fix for demux subs from playlist with multiple .m2ts files.
User avatar
Curly
Posts: 716
Joined: Sun Mar 15, 2020 11:05 am

Small difference in subtitles timing depending on how they are demuxed

Post by Curly »

thx harry i'm on it
Curly Howard
Director of EAC3TO Development
User avatar
Curly
Posts: 716
Joined: Sun Mar 15, 2020 11:05 am

Small difference in subtitles timing depending on how they are demuxed

Post by Curly »

OK, you are overwhelming me with too much data.
Just give me the two command lines that result in the sup files that have entries differing by 0.001 when using 3.46.
I don't need all those sup files, just the two command lines.
Thank you.
Curly Howard
Director of EAC3TO Development
DAE avatar
HPotter
Posts: 38
Joined: Thu Jul 29, 2021 9:54 am

Small difference in subtitles timing depending on how they are demuxed

Post by HPotter »

Curly wrote:
Sun Jan 14, 2024 7:09 am
Just give me the two command lines that result in the sup files that have entries differing by 0.001 when using 3.46.
First playlist mode:

Code: Select all

>eac3to "C:\Hairiötekija 2015 1080p FIN Blu-ray AVC DTS-HD MA 5.1-ESiR\BDMV\PLAYLIST\00533.mpls" 1) 6: fin.sup 7: swe.sup 8: fin1.sup
2nd direct .m2ts files mode for the same files:
157) 00533.mpls, 1:24:32
[107+109+106+108+103+105+113+116+111+104+114+1+112+115+110+102].m2ts

Code: Select all

eac3to "C:\Hairiötekija 2015 1080p FIN Blu-ray AVC DTS-HD MA 5.1-ESiR\BDMV\STREAM\00107.m2ts"+"C:\Hairiötekija 2015 1080p FIN Blu-ray AVC DTS-HD MA 5.1-ESiR\BDMV\STREAM\00109.m2ts"+"C:\Hairiötekija 2015 1080p FIN Blu-ray AVC DTS-HD MA 5.1-ESiR\BDMV\STREAM\00106.m2ts"+"C:\Hairiötekija 2015 1080p FIN Blu-ray AVC DTS-HD MA 5.1-ESiR\BDMV\STREAM\00108.m2ts"+"C:\Hairiötekija 2015 1080p FIN Blu-ray AVC DTS-HD MA 5.1-ESiR\BDMV\STREAM\00103.m2ts"+"C:\Hairiötekija 2015 1080p FIN Blu-ray AVC DTS-HD MA 5.1-ESiR\BDMV\STREAM\00105.m2ts"+"C:\Hairiötekija 2015 1080p FIN Blu-ray AVC DTS-HD MA 5.1-ESiR\BDMV\STREAM\00113.m2ts"+"C:\Hairiötekija 2015 1080p FIN Blu-ray AVC DTS-HD MA 5.1-ESiR\BDMV\STREAM\00116.m2ts"+"C:\Hairiötekija 2015 1080p FIN Blu-ray AVC DTS-HD MA 5.1-ESiR\BDMV\STREAM\00111.m2ts"+"C:\Hairiötekija 2015 1080p FIN Blu-ray AVC DTS-HD MA 5.1-ESiR\BDMV\STREAM\00104.m2ts"+"C:\Hairiötekija 2015 1080p FIN Blu-ray AVC DTS-HD MA 5.1-ESiR\BDMV\STREAM\00114.m2ts"+"C:\Hairiötekija 2015 1080p FIN Blu-ray AVC DTS-HD MA 5.1-ESiR\BDMV\STREAM\00001.m2ts"+"C:\Hairiötekija 2015 1080p FIN Blu-ray AVC DTS-HD MA 5.1-ESiR\BDMV\STREAM\00112.m2ts"+"C:\Hairiötekija 2015 1080p FIN Blu-ray AVC DTS-HD MA 5.1-ESiR\BDMV\STREAM\00115.m2ts"+"C:\Hairiötekija 2015 1080p FIN Blu-ray AVC DTS-HD MA 5.1-ESiR\BDMV\STREAM\00110.m2ts"+"C:\Hairiötekija 2015 1080p FIN Blu-ray AVC DTS-HD MA 5.1-ESiR\BDMV\STREAM\00102.m2ts" 6: fin_NEW.sup 7: swe_NEW.sup 8: fin1_NEW.sup
User avatar
Curly
Posts: 716
Joined: Sun Mar 15, 2020 11:05 am

Small difference in subtitles timing depending on how they are demuxed

Post by Curly »

Then which sup to look at? 6, 7, or 8? What lines? Give the start time of at least one line that is different.

I compare in SubtitleEdit for fin vs fin_NEW. It's hard to go through 700+ lines.
Curly Howard
Director of EAC3TO Development
DAE avatar
HPotter
Posts: 38
Joined: Thu Jul 29, 2021 9:54 am

Small difference in subtitles timing depending on how they are demuxed

Post by HPotter »

Curly wrote:
Sun Jan 14, 2024 7:57 am
Then which sup to look at? 6, 7, or 8? What lines?
For example you can look at fin vs fin_NEW
After 80 line - 81, 83, 84, 87, 89, 102, 477, 481, 490, 501, 502, 504 etc.
But it visible after OCR'ing by SubExtractor

Because of that I added .sup files and OCR'ed .srt.
User avatar
Curly
Posts: 716
Joined: Sun Mar 15, 2020 11:05 am

Small difference in subtitles timing depending on how they are demuxed

Post by Curly »

See below and show me the differences. Open them both in SubtitleEdit. Your OCR process is probably introducing the problem. And anyway, are we really going to obsess about a 1ms difference?

I'm not doing anything with OCR and all that.

Image
Curly Howard
Director of EAC3TO Development
DAE avatar
HPotter
Posts: 38
Joined: Thu Jul 29, 2021 9:54 am

Small difference in subtitles timing depending on how they are demuxed

Post by HPotter »

For 3.36 it was identical, just because of that wrote.
1 ms not big deal of course, just strange.
User avatar
Curly
Posts: 716
Joined: Sun Mar 15, 2020 11:05 am

Small difference in subtitles timing depending on how they are demuxed

Post by Curly »

I did a binary compare of the two sup files. I do see some places where the PTS values differ by 1. But that converts to an actual time difference of 22 microseconds. The resolution of the SubtitleEdit display is 1 millisecond. So that's why everything looks the same in SubtitleEdit. I guess the only way you can see a difference of 0.001 seconds (1 millisecond) using your process is due to some rounding up or something like that in your process.

The reason 3.36 is identical is because it uses a single algorithm for disk and non-disk, whereas 3.46 uses a different algorithm for each of those. I had to change the 3.36 method because it was broken for some disks (not all).

The bottom line is that for 3.46 the two methods should never differ by more than 22 microseconds, which is insignificant. Even if it was 1 millisecond it would still be insignificant as the threshold for humans to detect sync problems is about 20 milliseconds. It would be silly to spend any time on trying to make them identical. There is a bunch of abstruse code in the non-disk pathway (the 3.36 way) that I would have to spend a lot of time trying to decipher to be able to compare it to Rocky's disk algorithm. madshi's not a great fan of comments (at least in this codebase). No diss, just saying. So not going to do anything with this.

Marking resolved.
Curly Howard
Director of EAC3TO Development
Post Reply