MakeMKV 1.5.0 and audio Issues

[ragboy]

So I have downloaded 1.5 and took out some of my blu-rays that I have experienced issues with. The main issues are the garbled PCM issue, and TRUEHD parsing issue.

BRs like Kill Bill and Wild Hogs, the PCM track cannot be parsed or played. I have posted on this before, but even if I do a clean rip from makemkv and then play the resulting MKV on a player like the WD Live TV that supports PCM in mkvs, you get the garbled audio. On other BRs with PCM, it works fine.

The other issue is with TRUEHD tracks, even using eac3to to extract the TRUEHD tracks as described by mike:

eac3to title00.mkv 2:audio.TRUEHD

There are errors when converting many of these to other formats, usually causing a 1500ms delay that needs to be added. I haven't had a chance to really test the forced subs feature, but the audio is what has been of highest importance to me and I think others.

Its a great program, and shaping up well, I hope my testing can be beneficial to help make it better.

[mike admin]

It is a well known problem that eac3to can't presently parse multi-channel extended WAV and truehd in MKV container. Matthias, the author of eac3to promised to fix these in a next version, but apparently the next version is not yet ready. The .TRUEHD extraction mode is a hack.

Speaking of WD TV Live, can you please share how the direct UPnP streaming works with this device? MakeMKV should appear under "media servers" in about 10 seconds after you press stream button.

[ragboy]

Sure, I can report by tomorrow.

What about the PCM issue? There is the issue of incorrect channel order, and garbled with some BRs.

As far as truehd, I can also use ffmpeg to read the truehd track DIRECT from the mkv, and it has the same errors, not using eac3to at all.

[ragboy]

Here is what I get when I try to stream to the WD LIVE TV. I tried it with 2 BRs, and tried m2ts and ts, both same result on both BRs. I did get this to work for a few minutes with 1.4.12 and a HDX-BD1 box, but I stopped it, I was only testing. It worked, assumed it would have kept working. Don't know if the current issue is the version 1.5 or the WD. I don't have the HDX anymore, it fried.

[ragboy]

Sure, I can report by tomorrow.

What about the PCM issue? There is the issue of incorrect channel order, and garbled with some BRs.

As far as truehd, I can also use ffmpeg to read the truehd track DIRECT from the mkv, and it has the same errors, not using eac3to at all.

I ran a new test with 1.5. With 1.4 I did a BACKUP of the BR using makemkvcon and then with anydvd. The PCM was garbled with makemkv and fine with anydvd. I did a backup with 1.5, and now the pcm tracks works with eac3to, and it didn't before. So that is good. The one thing I think is similar to these BR PCM tracks, is that they are using BIG ENDIAN and not LITTLE ENDIAN. When I use eac3to on the backup, you see this:

a03 Extracting audio track number 3...
a03 Reading RAW/PCM...
a03 Swapping endian...
a03 Remapping channels...
a03 Encoding AAC <0.90> with NeroAacEnc...

So eac3to is sensing big endian. If you take the MKV that is made from the SAME BR, and check the header for the pcm track in the MKV, you see this:

Input #0, matroska, from 'title00.mkv':
Duration: 02:16:57.83, start: 0.000000, bitrate: 6912 kb/s
Stream #0.0(eng): Video: h264, yuv420p, 1920x1080, PAR 1:1 DAR 16:9, 23.98 tbr, 1k tbn, 47.95 tbc
Stream #0.1(eng): Audio: pcm_s24le, 48000 Hz, 6 channels (FL|FR|FC|LFE|BL|BR), s16, 6912 kb/s
Stream #0.2(eng): Audio: ac3, 48000 Hz, 5.1, s16
Stream #0.3(eng): Subtitle: 0x0000
Stream #0.4(eng): Subtitle: 0x0000

When I encode 600 secs like this and open the wav in soundstudio and look at the wavform and each channel, they are all garbled. But if I force BE like this:

ffmpeg -vn -acodec pcm_s24be -i title00.mkv -t 600 test_be.wav

I get mostly garbled, but actually 2 channels are correct. Channels 2 and 4 have correct data in them, and can be listened to.

[markb]

I have the exact same problems with the PCM being garbled.

Also...Extracting 2 audio tracks from Harry Potter Azkaban blu-ray (PCM and the Dolby AC3 tracks) allows PCM track and Dolby track to play but extracting just the LPCM track from the disk and the PCM track does not play.

Using 1.5.0 MakeMKV version as well.

[mike admin]

The one thing I think is similar to these BR PCM tracks, is that they are using BIG ENDIAN and not LITTLE ENDIAN. When I use eac3to on the backup, you see this:
So eac3to is sensing big endian. If you take the MKV that is made from the SAME BR, and check the header for the pcm track in the MKV, you see

Guys, PCM on BD is not only big endian, data encoding is Blu-ray specific. MakeMKV extracts and decodes PCM data, rearranges channels for WAV order and converts to little-endian. Let's wait unitl eac3to will have a proper multi-channel extractor from MKV and see if output is garbled. Meanwhile, as you correctly observed, you can use eac3to with M2TS files from decrypted backup.

[ragboy]

Regarding the TRUEHD issues.

1. I can bypass eac3to and just use ffmpeg like so:

ffmpeg -vn -acodec mlp -i title00.mkv -map 0.1:0.0 -t 600 -ac 6 test.wav

This produces the same errors if I first use eac3to title00.mkv audio.TRUEHD to extract out the track, then eac3to to convert. If I use ffmpeg as I do above on the same mkv that has both a AC3 track and a TRUEHD track, then you look at the waveform, you can see the wavefrom from the track that came from the TRUEHD track is early and needs a delay added to match up with the AC3 track.

I think I would be happy, if I knew a way to calculate the delay needed based on the errors, it is usually 1500ms, but not always, perfect storm was like 850ms or something like that.

[ragboy]

The one thing I think is similar to these BR PCM tracks, is that they are using BIG ENDIAN and not LITTLE ENDIAN. When I use eac3to on the backup, you see this:
So eac3to is sensing big endian. If you take the MKV that is made from the SAME BR, and check the header for the pcm track in the MKV, you see

Guys, PCM on BD is not only big endian, data encoding is Blu-ray specific. MakeMKV extracts and decodes PCM data, rearranges channels for WAV order and converts to little-endian. Let's wait unitl eac3to will have a proper multi-channel extractor from MKV and see if output is garbled. Meanwhile, as you correctly observed, you can use eac3to with M2TS files from decrypted backup.

I have to check something on pcm, but I can answer one issue above. When I experenced this error, doing a backup with makemkvcon didn't fix the issue. The PCM was garbled using eac3to on the m2ts also. However, the backup with 1.5.0 now works. When the issue came up before, I had to use anydvd and eac3to, makemkv was garbling the pcm to both the backup m2ts and the mkv.

[ragboy]

Guys, PCM on BD is not only big endian, data encoding is Blu-ray specific. MakeMKV extracts and decodes PCM data, rearranges channels for WAV order and converts to little-endian. Let's wait unitl eac3to will have a proper multi-channel extractor from MKV and see if output is garbled. Meanwhile, as you correctly observed, you can use eac3to with M2TS files from decrypted backup.

I will do a test, to be sure, but I think that is my point. That makemkv is not swapping endian correctly for some of these titles. If it did, then when I told ffmpeg to use BE to read the pcm track, all of the tracks should have been garbled, but 2 of them, were clean and correct.

[ragboy]

The one thing I think is similar to these BR PCM tracks, is that they are using BIG ENDIAN and not LITTLE ENDIAN. When I use eac3to on the backup, you see this:
So eac3to is sensing big endian. If you take the MKV that is made from the SAME BR, and check the header for the pcm track in the MKV, you see

Guys, PCM on BD is not only big endian, data encoding is Blu-ray specific. MakeMKV extracts and decodes PCM data, rearranges channels for WAV order and converts to little-endian. Let's wait unitl eac3to will have a proper multi-channel extractor from MKV and see if output is garbled. Meanwhile, as you correctly observed, you can use eac3to with M2TS files from decrypted backup.

Huh, looks like it just came out, lets see. At least for the truehd issue.

http://forum.doom9.org/showthread.php?p ... ost1381525

[ragboy]

3.18 is still showing the errors on truehd in mkv, but now can parse them without hack, and can also parse PGS to SUP.

Code: Select all

[rgarcia@fs2 PERFECT_STORM_NA_EU_JP]$ wine32 eac3to "Perfect Storm.mkv" 3:hdaudio_eac18.m4a -quality=0.9 7:sub1.sup 8:sub2.sup
Hooking GetModuleFileNameA failed (Invalid parameter).                         
Hooking WriteConsoleA failed (Success).                                        
MKV, 1 video track, 5 audio tracks, 2 subtitle tracks, 2:09:49, 24p /1.001     
1: VC-1, 1080p24 /1.001 (16:9)                                                 
2: AC3 EX, English, 5.1 channels, 640kbps, 48khz, dialnorm: -27dB              
   "3/2+1"                                                                     
3: TrueHD, English, 5.1 channels, 48khz, dialnorm: -27dB                       
   "5.1"                                                                       
4: AC3 Surround, English, 2.0 channels, 192kbps, 48khz, dialnorm: -27dB        
   "2/0"                                                                       
5: AC3 Surround, English, 2.0 channels, 192kbps, 48khz, dialnorm: -27dB        
   "2/0"                                                                       
6: AC3 Surround, English, 2.0 channels, 192kbps, 48khz, dialnorm: -27dB        
   "2/0"                                                                       
7: Subtitle (PGS), English                                                     
8: Subtitle (PGS), English                                                     
a03 Extracting audio track number 3...                                         
a03 Removing TrueHD dialog normalization...                                    
a03 Decoding with libav/ffmpeg...                                              
a03 Encoding AAC <0.90> with NeroAacEnc...                                     
[mlp @ 009F32E0]Lossless check failed - expected 0, calculated 3
[mlp @ 009F32E0]Lossless check failed - expected 0, calculated fa
[mlp @ 009F32E0]Lossless check failed - expected 0, calculated 4
[mlp @ 009F32E0]Lossless check failed - expected 0, calculated 4
[mlp @ 009F32E0]Lossless check failed - expected 0, calculated fb
[mlp @ 009F32E0]Lossless check failed - expected 0, calculated f8
[mlp @ 009F32E0]Lossless check failed - expected 0, calculated ff
[mlp @ 009F32E0]Lossless check failed - expected 0, calculated fb
[mlp @ 009F32E0]Lossless check failed - expected 0, calculated fc
s08 Extracting subtitle track number 8...                                      
s07 Extracting subtitle track number 7...                                      
s08 Creating file "sub2.sup"...                                                
s07 Creating file "sub1.sup"...                                                
------

[ragboy]

The one thing I think is similar to these BR PCM tracks, is that they are using BIG ENDIAN and not LITTLE ENDIAN. When I use eac3to on the backup, you see this:
So eac3to is sensing big endian. If you take the MKV that is made from the SAME BR, and check the header for the pcm track in the MKV, you see

Guys, PCM on BD is not only big endian, data encoding is Blu-ray specific. MakeMKV extracts and decodes PCM data, rearranges channels for WAV order and converts to little-endian. Let's wait unitl eac3to will have a proper multi-channel extractor from MKV and see if output is garbled. Meanwhile, as you correctly observed, you can use eac3to with M2TS files from decrypted backup.

eac3to 3.18 now properly parses the PCM tracks from MakeMKV, however, output from the "troubled" BRs that I have mentioned, are still garbled.

Code: Select all

[rgarcia@fs2 KILLBILL2_US]$ wine32 eac3to title00.mkv 2:hdaudio.m4a -quality=0.9
Hooking GetModuleFileNameA failed (Invalid parameter).                         
Hooking WriteConsoleA failed (Success).                                        
MKV, 1 video track, 2 audio tracks, 2 subtitle tracks, 2:16:58, 24p /1.001     
1: h264/AVC, 1080p24 /1.001 (16:9)                                             
2: RAW/PCM, English, 5.1 channels, 24 bits, 48khz                              
   "3/2+1"                                                                     
3: AC3, English, 5.1 channels, 640kbps, 48khz                                  
   "3/2+1"                                                                     
4: Subtitle (PGS), English                                                     
5: Subtitle (PGS), English                                                     
a02 Extracting audio track number 2...                                         
a02 Reading RAW/PCM...                                                         
a02 Encoding AAC <0.90> with NeroAacEnc...                                     
a02 The original audio track has a constant bit depth of 24 bits.              
Video track 1 contains 394061 frames.                                          
eac3to processing took 30 minutes, 2 seconds.                                  
Done.       

[ragboy]

Bump, have you had a chance to confirm this?

[mike admin]

Current version of MakeMKV, 1.5.1, for LPCM from BD sources, produces output with wrong channel order for 16-bit 5.1 and 7.1 configurations and outputs white noise for 20-bit and 24-bit audio regardless of speaker configuration. 16-bit stereo 3/0,2/1 and 2/2 are correct.

It is a shame and it will be corrected in a next version.