"The Island" audio dropouts

[gbooker]

I'm having issues with the BD "The Island" and I was wondering if others were experiencing issues. On average of about once every 1-3 minutes, the audio will dropout momentarially during playback (as if it were dropping a single audio frame). The dropouts are never in the same place twice, but same areas of the movie are more problematic than others, such as the title sequence. I'm using the same technique for ripping my BDs as I've done for the past 50, and this is the first that has given me problems. I'm providing excessive detail in case it'd be useful.

Here's my ripping setup:

1. Rip with MMKV excluding everything except for the English DTS and DTS-HD (or DD and DD TrueHD) and forced English subs.
2. Since I've had issues with playback, I remux the resulting MKV using mkvmerge re-ordering the DTS track before the DTS-HD (my player ignores the enabled and default flags, but instead plays the first audio track initially).
3. Extract chapters and modify titles to those from chaptersdb.org (if present).
4. Stream the MKV over http to a GoogleTV (Sony NSZ-GT1). Wired ethernet (gigabit) to base station, 802.11n (5GHz band) to player (10 feet).
5. Use DTS (and AC3) passthrough to a decoder (Sony STR-K790) connected via optical.

Fairly simple, and has worked well for other disks. Occasionally this involves appending two MKVs (or 6 in once case) if the titles are split. BTW, the issue I had with DTS-HD would involve the audio dropping out and never returning about once every 30-60 minutes. Stoping playback and resuming will work for another 30-60 minutes.

What I've tried. Performs the same unless otherwise noted:

1. The setup as above ripping with 1.8.0 on Ubuntu.
2. Handbrake 1's MKV using DTS passthrough but transcoding the video (High-Profile, CRF 19). I thought the issue may be the size of the origonal rip as it was around 40G, but I have shorter movies in that size range that have no issues.
3. Running 1's result through mkvmerge again (performs better but starts dropouts at a later time).
4. Running 2's result through mkvmerge (no noticable change).
5. Running the above over wired ethernet from server all the way to player.
6. Stripping out all the elementary streams into 3 raw stream files and recombining. This lead to the audio/video drifting out of sync (it starts in sync). I did set "--default-duration 0:24000/1001fps" for the H.264 stream so I don't know what the deal is here. This is what I find to be the most disturbing.
7. The original proceduce with 1.7.10 (3 dropouts in 30 min).
8. The original proceduce with 1.7.10 but excluding the DTS-HD track (when audio dropped, it never returned, just like DTS-HD would do on this player).
9. Restarting the player and running 7 again (1 in 45 minutes and playing as I write this).

I wouldn't judge the differences between 1-5 as significant differences as the dropouts are a random process and the differences could correspond to a processes with the same mean. 7 and 9 do seem to be outliers, and I don't have any good rational as to why that may be the case.

Does anyone have any clues what may be going on or how to fix it? Has anyone else had issues with this title? I'm not sure if this is an MMKV problem, but I thought I'd ask here in case others had some thoughts.

[mike admin]

Do you have "show AV sync issues" enabled in MakeMKV preferences? If yes, did you get any messages during conversion?

[gbooker]

I did not have it enabled. I ripped again and it did not report any messages other than to say that the forced subtitle track was empty and removed. I have not tried playback of this file, as I am checking the progress remotely, but since this would now be the 4th rip, it's unlikely to be any different. BTW, I have switched back to running 1.8.0.

After I ripped, I noticed the prefs had a log debug messages which I also had off. I turned it on and started another rip to see if it reports anything.

[gbooker]

The debug log only contained:
005014:0000 Saving 1 titles into directory ....
001003:0020 DEBUG: Code 0 at i%P\WzDX118g1dhnKF}ox`z:213130122
004001:0000 Forced subtitles track #3 turned out to be empty and was removed from output file
005005:0080 1 titles saved
005036:0104 Copy complete. 1 titles saved.