Are Avatar's (2D & 3D Blu-ray) subtitles incorrect/out of spec?

[Stereodude]

I have the US release 2D and 3D Blu-rays of Avatar. I'm trying to rip them to a respective .mkv with subtitles that works correctly on my Zidoo Z9X. The Zidoo won't scan a subtitle track for individually flagged forced subtitles like MPC-HC will so it need a separate track that is flagged as forced in the mkv header. MakeMKV 1.17.1 with the (forced only option) generates mkv files that do do not display the subtitles correctly when played in either MPC-HC or on my Zidoo Z9X. The files when played will show non-forced subtitles that are in close time proximity to the forced subtitles. This doesn't make a whole lot of sense since the active subtitle track has only 165 on the 2D and 166 elements per mediainfo. There are 83 forced subtitles (I think) so I don't really understand how the extra "forced" track MakeMKV made could have the extra subtitles in it that it's displaying, but I can't really open them to check.

I've extracted the MakeMKV created "forced only" subtitle track from both the mkv of the 2D version and the mkv of the 3D version. BDSup2Sub 5.1.2 won't open either .sup and crashes (same error).



I figured maybe MakeMKV wasn't handling the disc correctly, so I also ripped and demuxed the English .sup track the 2D disc has several additional ways.

MakeMKV [direct] to mkv + MKVextract
AnyDVD HD + TSmuxer
AnyDVD HD + eac3to
AnyDVD HD + DGDemux

None of the .sup files from these 4 methods are bit identical. However, they all load in BDSup2Sub 5.1.2 with 346 warnings and 2033 subtitles (83 of which are forced).

Log: https://pastebin.com/7XgWBBRm

Using BDSup2Sub 5.1.2 to export only the 83 forced subtitles from those .sup files from the 2D Avatar Blu-ray generates 25 warnings (WARNING: Problems during RLE decoding of picture OBJ at offset...).

Log: https://pastebin.com/FW1fC1qG

This yields a file that when reopened in BDSup2Sub only has 75 subtitles instead of 83 and some of the 75 it has are blank. There are some number of "caption merged" messages in the log window.

Log: https://pastebin.com/a3P37gsy

I tried muxing this forced only track from BDSup2Sub 5.1.2 to test it another way. It basically does what you'd expect. Only displaying the subtitles that are in the .sup that also have an image.

DGDemux's "forced subs only" option for the 2D Blu-ray also generates a file that BDSup2Sub 5.1.2 won't open with the same crash seen when trying to open it.



Muxing the 2D's forced track from DGDemux (that I can't open in BDSup2Sub 5.1.2) also doesn't play back correctly in MPC-HC. Some non-forced subtitles appear (not exactly the same as the MakeMKV created rendition) and the last subtitle for a given scene with Na'vi from the forced track seems to hang on the screen indefinitely.

On the 3D disc, the different methods of getting the .sup also makes files that aren't bit identical. They open in BDSup2Sub 5.1.2 with 359 warnings and 1983 subtitles (83 of which are forced).

Log: https://pastebin.com/5D5p8SYr

I can export the 83 forced subtitles with BDSup2Sub 5.1.2. I only get 1 warning.

Log: https://pastebin.com/HxyNtqrb

This yields a file that when reopened in BDSup2Sub seems okay. It has 83 forced subtitles and they all have an image.

Muxing this track into the 3D .mkv seems to work correctly.

DGDemux's "forced subs only" option for the 3D Blu-ray generates a file that BDSup2Sub 5.1.2 won't open with the same crash seen when trying to open it.



Muxing the 3D's forced track from DGDemux (that I can't open in BDSup2Sub 5.1.2) also doesn't play back correctly in MPC-HC. Some non-forced subtitles appear (not exactly the same as the MakeMKV created rendition) and the last subtitle for a given scene with Na'vi from the forced track seems to hang on the screen indefinitely.


Do the Blu-rays of Avatar have subtitles that are out of spec or are unusual in some way that causes nearly all the software tools not be able to process/handle them?
Is there another program beside BDSup2Sub 5.1.2 that I can use to check the .sup files or export only the forced subtitles?

[cubicibo]

Hi,
A sample would be very helpful to give you a more definitive reply. Chances are that they are in spec but they use some functionality unknown to the peasants (us).
While this is not guaranteed to work, try to produce a sample using pball pgs splitter. If that doesn't look right on playback, just use a hexeditor and save maybe 1/4 of the source .sup file to a new file, where you expect forced subtitles to be.

[von Suppé]

As for the bdsup2sub issues, all versions do have their own bugs. Have you tried version ++1.0.4b? I know some problems already have been solved. You may wanna read from here:
https://forum.doom9.org/showthread.p...56#post1969456

Also, maybe another tool can help out. Subtitle Edit has the option to import "Blu-ray SUP for edit". It's an editor for image based subtitles, bit similar to bdsup2sub.

I remember, waaayyy back, having struggled too with the problematic Avatar 3D subtitles. The disc indeed seemed to have some odd authoring for PGS. I ended up OCR-ing the PGS stream. Using the correct font and a subtitle-positions cloning tool, I created a whole new "Na'vi only" PGS track. I never encountered any 3D playback issues with them. On standalone players that is; I wouldn't know about SW players.

[Stereodude]

Originally Posted by von Suppé

As for the bdsup2sub issues, all versions do have their own bugs. Have you tried version ++1.0.4b? I know some problems already have been solved. You may wanna read from here:
https://forum.doom9.org/showthread.p...56#post1969456

Thanks for the reply and pointing that out. ++1.0.4b will open the files that BDSup2Sub 5.1.2 won't. It doesn't crash. It doesn't generate any warnings. It does try to merge some of the subtitles in the 2D .sup though (regardless of whether eac3to, tsmuxer, DGDecode, or MakeMKV processed them).

#< caption 1959 merged with caption 1958
#< caption 1925 merged with caption 1924
#< caption 1260 merged with caption 1259
#< caption 861 merged with caption 860
#< caption 738 merged with caption 737
#< caption 560 merged with caption 559
#< caption 280 merged with caption 279
#< caption 31 merged with caption 30

On the 3D .sup

#< caption 1103 merged with caption 1102
#< caption 817 merged with caption 816

I'm not sure why.

I can now see that MakeMKV and DGDemux include non-forced subtitles in their "forced only" track subs (the extra ones that appear during playback). I'm not entirely sure how to square this with the element counts shown in MediaInfo. I also see that the subtitles that hang indefinitely from DGDemux's forced only .sup file are coded that way in the .sup with an end time that's the same as the start of the next subtitle.

Exporting forced only from the 2D .sup with ++1.0.4b results in a .sup file that reopens fine without error (even in 5.1.2), has only the 83 forced subtitles, none are blank. However when that .sup is muxed into the .mkv the position of the subs during playback is wrong. I see in the GUI that the pos: looks all messed up.



So, it looks like both MakeMKV and DGDecode have "bugs" when processing the Avatar Blu-rays for forced subtitles only. BDSup2Sub ++1.0.4b looks to have an issue with the positioning of the forced subtitles. 5.1.2 doesn't do that. It looks like this positioning issue was already identified here.

Also, maybe another tool can help out. Subtitle Edit has the option to import "Blu-ray SUP for edit". It's an editor for image based subtitles, bit similar to bdsup2sub.

It looks to insist on doing OCR to get them into a text format. It will open the .sup files without issue. I just can't do anything with them (that I can figure out) aside from OCR'ing them.

[Stereodude]

Originally Posted by cubicibo

Hi,
A sample would be very helpful to give you a more definitive reply. Chances are that they are in spec but they use some functionality unknown to the peasants (us).
While this is not guaranteed to work, try to produce a sample using pball pgs splitter. If that doesn't look right on playback, just use a hexeditor and save maybe 1/4 of the source .sup file to a new file, where you expect forced subtitles to be.

The original .sup files aren't that big. They're under 40MB. What file host are people using lately?

[von Suppé]

Try MEGA https://mega.io/desktop

Originally Posted by Stereodude

It looks to insist on doing OCR to get them into a text format. It will open the .sup files without issue. I just can't do anything with them (that I can figure out) aside from OCR'ing them.

I think you're importing them wrongly. Go "File --> Import --> Blu-ray (.sup) subtitle file for edit"

Originally Posted by Stereodude

So, it looks like both MakeMKV and DGDecode have "bugs" when processing the Avatar Blu-rays for forced subtitles only.

Processing forced subs from (UHD)BD has always been a challenge since they can be authored in different ways to be displayed seemingly "by force". Sometimes a separate PGS track is created without even a forced flag. And can be dictated to play (or not) by e.g. disc-menu options a viewer has to select. Player's default subtitle settings may also co-decide on whether "forced" subs are played.
You can imagine demuxers/SUP handlers behaving differently.

[Stereodude]

Originally Posted by von Suppé

Try MEGA https://mega.io/desktop

Thanks. I'll see about getting them uploaded a little later.

I think you're importing them wrongly. Go "File --> Import --> Blu-ray (.sup) subtitle file for edit"

You're right. I didn't see that. This method opens them in a non-OCR editing method. Deleting all the non-forced ones is tedious, but Subtitle Edit allowed me to save a forced only .sup file that subsequently opens fine in BDSup2Sub 5.1.2 and ++1.0.4b. There are no goofy positions reported in ++1.0.4b with the file exported from Subtitle Edit. When muxed into the .mkv they work as expected during playback with no odd positioning or other issues.

Edit: It also seems that the subtitles ++1.0.4b is merging with the one next to it is because some of them have too short of a duration (reported per Subtitle Edit). I'm not sure what is the actual allowed minimum by Blu-ray spec.

Also, it's possible to use Subtitle Edit to in effect "heal" the .sup file. I can open the .sup file from the demuxer, make no changes to it, and then save it to a new file. The saved output will open in BDSup2Sub 5.1.2 without any warnings and then BDSup2Sub 5.1.2 can then do a forced only export without any warnings that also opens fine without any position errors, missing subtitles, or blank subtitles.

Processing forced subs from (UHD)BD has always been a challenge since they can be authored in different ways to be displayed seemingly "by force". Sometimes a separate PGS track is created without even a forced flag. And can be dictated to play (or not) by e.g. disc-menu options a viewer has to select. Player's default subtitle settings may also co-decide on whether "forced" subs are played.
You can imagine demuxers/SUP handlers behaving differently.

I know there's multiple ways to do it. AFAIK, these "forced only" options in MakeMKV and DGDecode are only supposed to extract the individually flagged forced subtitles from a given subtitle stream. The kind selected by the play command from the disc's menu aren't handled by this "forced only" method.

[Stereodude]

Originally Posted by cubicibo

Hi,
A sample would be very helpful to give you a more definitive reply. Chances are that they are in spec but they use some functionality unknown to the peasants (us).
While this is not guaranteed to work, try to produce a sample using pball pgs splitter. If that doesn't look right on playback, just use a hexeditor and save maybe 1/4 of the source .sup file to a new file, where you expect forced subtitles to be.

Here's the 3D .sup and 2D .sup that I extracted from the respective Blu-ray.

http://stereodude.net/US_Avatar_2D&3D_Subtitles_sup.7z

[cubicibo]

SUPer parses 1985 objects (pictures) among 15509 segments for the 3D BD. 83 compositions objects are forced, but the arrangement of the stream is quite uncommon:

Epoch Start:
• [PCS, WDS, PDS, ODS, END] <-- show the graphics
• [PCS, WDS, PDS*, END] <-- clear the screen
• [PCS, WDS, PDS, ODS, END] <-- show a new graphics in the epoch
• [PCS, WDS, PDS*, END] <-- clear the new graphics
(...) until they notice that maybe a new epoch is necessary.

Where PDS denoted with * are an empty palette (palette update flag is False, palette id is incremented by 1) and the PCS has no composition object. AFAIK you just need to clear the Composition objects and eventually the window, not redefine the windows and empty the palette... unless they do as they're afraid redefining the WDS later on can cause flickering… (has anyone a take on that?)

Now, as to why you're getting close-by subtitles, I am positive it's because they sometime set the forced flag in the middle of the epoch, so possibly most software may lazily copy the whole epoch rather than the forced graphics. Also yes, the forced flag is uncommon in general so some software may not parse the file appropriately.

If you know some Python, you could use SUPer to extract the forced composition to a new file. This is what I used to count the forced PCS:

supstream = SupStream('thefile.sup')
segs = [seg for seg in supstream.fetch_segment()]
cnt=0
for seg in segs:
    if seg.type == 'PCS':
        for cob in seg.cobjects:
            if cob.forced:
                cnt += 1

You could cycle through the epochs

forced_ds = []
for epoch in supstream.epochs():
    for ds in epoch.ds:
        if save_next_ds:
             forced_ds.append(ds)
             save_next_ds = False
             continue 
        for cob in ds[0].cobjects: #first segment in DisplaySet is always a PCS
            if cob.forced:
                forced_ds.append(ds) # save the DS in some list and set the PCS composition flag to EPOCH_START.
                save_next_ds = True # We need to save the next DS as it undisplay this graphics.
                break
#Then here you just overwrite the PCS composition flag to EPOCH_START and save the content to a file.

Of course, this simplistic will not work properly if there are numerous objects on screen and one of the object is forced.

[Stereodude]

Originally Posted by cubicibo

SUPer parses 1985 objects (pictures) among 15509 segments for the 3D BD. 83 compositions objects are forced, but the arrangement of the stream is quite uncommon:

Epoch Start:
• [PCS, WDS, PDS, ODS, END] <-- show the graphics
• [PCS, WDS, PDS*, END] <-- clear the screen
• [PCS, WDS, PDS, ODS, END] <-- show a new graphics in the epoch
• [PCS, WDS, PDS*, END] <-- clear the new graphics
(...) until they notice that maybe a new epoch is necessary.

Where PDS denoted with * are an empty palette (palette update flag is False, palette id is incremented by 1) and the PCS has no composition object. AFAIK you just need to clear the Composition objects and eventually the window, not redefine the windows and empty the palette... unless they do as they're afraid redefining the WDS later on can cause flickering… (has anyone a take on that?)

Now, as to why you're getting close-by subtitles, I am positive it's because they sometime set the forced flag in the middle of the epoch, so possibly most software may lazily copy the whole epoch rather than the forced graphics. Also yes, the forced flag is uncommon in general so some software may not parse the file appropriately.

If you know some Python, you could use SUPer to extract the forced composition to a new file. This is what I used to count the forced PCS:

supstream = SupStream('thefile.sup')
segs = [seg for seg in supstream.fetch_segment()]
cnt=0
for seg in segs:
    if seg.type == 'PCS':
        for cob in seg.cobjects:
            if cob.forced:
                cnt += 1

You could cycle through the epochs

forced_ds = []
for epoch in supstream.epochs():
    for ds in epoch.ds:
        if save_next_ds:
             forced_ds.append(ds)
             save_next_ds = False
             continue 
        for cob in ds[0].cobjects: #first segment in DisplaySet is always a PCS
            if cob.forced:
                forced_ds.append(ds) # save the DS in some list and set the PCS composition flag to EPOCH_START.
                save_next_ds = True # We need to save the next DS as it undisplay this graphics.
                break
#Then here you just overwrite the PCS composition flag to EPOCH_START and save the content to a file.

Of course, this simplistic will not work properly if there are numerous objects on screen and one of the object is forced.

Interesting... Thanks for the detective work.