eac3to - audio conversion tool

[Joniii]

Here's a small THD sample from Finding Nemo. It demuxed fine from BD but the demuxed file doesn't seem to have AC3 core, also when trying to encode to AC3 it fails. I also have this exact same problem with Total Recall.

H:\eac3to>eac3to e:\nemo.thd d:\nemo.ac3
TrueHD, 7.1 channels, 48kHz
AC3 encoding doesn't support back channels. Will mix them into the surround.
Decoding with libav/ffmpeg...
Remapping channels...
Mixing surround channels...
Encoding AC3 <640kbps> with libAften...
[mlp @ 00b42d10] Substream 0 parity check failed
[mlp @ 00b42d10] Substream 0 checksum failed
[mlp @ 00b42d10] Substream 0 length mismatch.
The libav decoder reported error -1 while decoding.

Sample (http://sdrv.ms/TKwiu4)

[jj666]

Hi Madshi,

There are two outstanding fixes mentioned here (http://forum.doom9.org/showthread.php?p=1428982#post1428982) (and the post above) regarding the stripping of DTS-HD Master Audio Suite headers needing adjustment, and issues with audio delays when two passes are needed.

Cheers,

-jj-

[tebasuna51]

@tebasuna51, would you be willing to make a list of the most important things to fix in / add to eac3to? Not too big things, please, just bugfixes and minor changes/improvements. Thanks!

Maybe the best option is open the source code like was sugessted many times in this thread.

BTW, I open a new thread eac3to v3.24 Bugs & Improvements (http://forum.doom9.org/showthread.php?p=1600693#post1600693)

[madshi]

Thanks, I'll have a look at that new thread. It might take a week or two or three before I get to this, though.

[sporic]

Several new BD's with TrueHD have problems, for example it's impossible to directly encode TrueHD to DTS or AC3 with EAC3TO, it gives some red warnings and hangs. Also demuxing THD works but demuxing THD with AC3 fails.


[mlp @ 00b42d10] Substream 0 parity check failed
[mlp @ 00b42d10] Substream 0 checksum failed
[mlp @ 00b42d10] Substream 0 length mismatch.
a03 The libav decoder reported error -1 while decoding.


What's new in these TrueHD tracks that's causing these problems?

[rapscallion]

What's new in these TrueHD tracks that's causing these problems?
Someone previously suggested that it has to do with seamless branching. Although I've had no problem in the past with that.

[tebasuna51]

Someone previously suggested that it has to do with seamless branching.

Nope, I extracted the .thd's directly from .m2ts's (with eac3to and tsMuxeR) of BD Brave, and when try decode with eac3to all crash with this error.

ffmpeg decode the thd's without problem.

Maybe -libav need a update.

[rapscallion]

Nope, I extracted the .thd's directly from .m2ts's (with eac3to and tsMuxeR) of BD Brave, and when try decode with eac3to all crash with this error.

ffmpeg decode the thd's without problem.

Maybe -libav need a update.
Funny, ffmpeg didn't work for me :(


[truehd @ 023cc440] max_analyze_duration 5000000 reached at 5000000
[truehd @ 023cc440] Estimating duration from bitrate, this may be inaccurate
Input #0, truehd, from 'track_4352.thd':
Duration: N/A, start: 0.000000, bitrate: N/A
Stream #0:0: Audio: truehd, 48000 Hz, 7.1, s32
Output #0, flac, to 'track_4352.flac':
Metadata:
encoder : Lavf54.36.100
Stream #0:0: Audio: flac, 48000 Hz, 7.1, s32, 128 kb/s
Stream mapping:
Stream #0:0 -> #0:0 (truehd -> flac)
Press [q] to stop, [?] for help
Lossless check failed - expected 00, calculated f4.s/s
Lossless check failed - expected 00, calculated 65.s/s
Lossless check failed - expected 00, calculated dc.s/s
End of stream indicated.40:25.24 bitrate=2975.9kbits/s
[truehd @ 024c0900] restart header sync incorrect (got 0x0685)
Error while decoding stream #0:0: Invalid data found when processing input
Last message repeated 3 times
[truehd @ 024c0900] restart header sync incorrect (got 0x0d60)
Error while decoding stream #0:0: Invalid data found when processing input
Last message repeated 3 times
[truehd @ 024c0900] too many audio samples in frame
Error while decoding stream #0:0: Invalid data found when processing input
[truehd @ 024c0900] too many audio samples in frame
Error while decoding stream #0:0: Invalid data found when processing input
[truehd @ 024c0900] too many audio samples in frame
Error while decoding stream #0:0: Invalid data found when processing input
Last message repeated 1 times
[truehd @ 024c0900] too many audio samples in frame
Error while decoding stream #0:0: Invalid data found when processing input
Last message repeated 1 times
[truehd @ 024c0900] restart header sync incorrect (got 0x1556)
Error while decoding stream #0:0: Invalid data found when processing input
[truehd @ 024c0900] Lossless check failed - expected 07, calculated e0.
size= 2195470kB time=01:40:53.96 bitrate=2970.8kbits/s
video:0kB audio:2195462kB subtitle:0 global headers:0kB muxing overhead 0.000367
%

C:\Dvd_rw\ffmpeg\bin>

Plus, I could extract with eac3to, but not create "wavs".

[tebasuna51]

With the thd extracted from 00954.m2ts (Brave BD):

ffmpeg version N-44601-gcb3591e Copyright (c) 2000-2012 the FFmpeg developers
built on Sep 19 2012 16:28:01 with gcc 4.7.1 (GCC)
...
[truehd @ 023ecf60] max_analyze_duration 5000000 reached at 5000000
[truehd @ 023ecf60] Estimating duration from bitrate, this may be inaccurate
Input #0, truehd, from 'D:\Temp\t003.thd':
Duration: N/A, start: 0.000000, bitrate: N/A
Stream #0:0: Audio: truehd, 48000 Hz, 7.1, s32
Output #0, wav, to 'audio.wav':
Metadata:
encoder : Lavf54.27.101
Stream #0:0: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 48000 Hz, 7.1, s16, 6144 kb/s
Stream mapping:
Stream #0:0 -> #0:0 (truehd -> pcm_s16le)
Press [q] to stop, [?] for help
End of stream indicated.02:56.87 bitrate=6143.2kbits/s
size= 136856kB time=00:03:02.47 bitrate=6144.0kbits/s
video:0kB audio:136856kB subtitle:0 global headers:0kB muxing overhead 0.000049%

[ron spencer]

I have same issue...eac3to and tsmuxer both crash...is there a way to demux from the m2ts in the playlist...I like to convert to ac-3 448...why is this truehd stream so weird...it has worked b4

[soneca]

With the thd extracted from 00954.m2ts (Brave BD):

tebasuna51,

This same blu-ray(Brave) shows me the main audio track as Dolby Digital Plus(E-AC-3) with 7.1 channels.

[Joniii]

Thanks, I'll have a look at that new thread. It might take a week or two or three before I get to this, though.

Put madVR on hold. Ripping Blu-rays should be priority.

[lmaolmao]

eac3to does not seem to be able to extract the .thd+ac3 on the brave/nemo discs it tries to start making an ac3 core using aften.

set it to demux just .thd and it spits out a file, set it to .ac3 and it spits out a file (neither one encoding), but when you want a .thd+ac3 file it fails.



M2TS, 1 video track, 8 audio tracks, 13 subtitle tracks, 1:40:54, 24p /1.001
1: Chapters, 32 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: TrueHD/AC3, English, 7.1 channels, 48kHz
(embedded: AC3 EX, 5.1 channels, 640kbps, 48kHz)
4: AC3 Surround, English, 2.0 channels, 320kbps, 48kHz
5: AC3 EX, Czech, 5.1 channels, 640kbps, 48kHz
6: AC3 EX, Slovak, 5.1 channels, 640kbps, 48kHz
7: AC3 EX, Arabic, 5.1 channels, 640kbps, 48kHz
8: AC3 EX, Russian, 5.1 channels, 640kbps, 48kHz
9: AC3 EX, Ukrainian, 5.1 channels, 640kbps, 48kHz
10: AC3 EX, Croatian, 5.1 channels, 640kbps, 48kHz
11: Subtitle (PGS), English
12: Subtitle (PGS), English
13: Subtitle (PGS), Czech
14: Subtitle (PGS), Slovak
15: Subtitle (PGS), Arabic
16: Subtitle (PGS), Russian
17: Subtitle (PGS), Ukrainian
18: Subtitle (PGS), Croatian
19: Subtitle (PGS), Slovak
20: Subtitle (PGS), Arabic
21: Subtitle (PGS), Ukrainian
22: Subtitle (PGS), Croatian
23: Subtitle (PGS), Czech
a03 AC3 encoding doesn't support back channels. Will mix them into the surround.

a03 Extracting audio track number 3...
a03 Extracting TrueHD stream...
a03 Extracting audio track number 3...
a03 Extracting TrueHD stream...
a03 Decoding with libav/ffmpeg...
a03 Remapping channels...
a03 Mixing surround channels...
a03 Encoding AC3 <640kbps> with libAften...
a03 libav Substream 0 parity check failed
a03 libav Substream 0 checksum failed
a03 libav Substream 0 length mismatch.
a03 The libav decoder reported error -1 while decoding.


I hadn't noticed this mentioned in the thread. Is this why some are having trouble remuxing?

[hoju3508]

@lmaolmao, this "a03 The libav decoder reported error -1 while decoding." is a known problem for eac3to.

[BigPines]

@lmaolmao, this "a03 The libav decoder reported error -1 while decoding." is a known problem for eac3to.

I've been using eac3to for years and never got this error until Brave. Unfortunately, this is a pretty bad bug. It makes it impossible to demux Brave or convert the audio using eac3to.

Bummer...

Mike

[ron spencer]

you can demux the thd only...that is easy.

then use ffmpeg to convert to ac3 448...I just did that ...seems perfect. you just need and extra step.

hopefully eac3to can be fixed for this.

[lmaolmao]

@lmaolmao, this "a03 The libav decoder reported error -1 while decoding." is a known problem for eac3to.

maybe i am not making myself clear. This is happening before the -1 error.

with all other truehd discs you can extract a .thd file, the .ac3 core or a .tdh+ac3 file. And it just demuxes it (no encoding).

With BRave and Nemo, you can extract a .thd or the .ac3 core fine. But when extracting the .thd+ac3, eac3to initialises aften to make the ac3 track instead of just demuxing. Which is odd.....

[Boulder]

But when extracting the .thd+ac3, eac3to initialises aften to make the ac3 track instead of just demuxing. Which is odd.....Post the commandline so we can see if there's anything wrong with that.

[lmaolmao]

Post the commandline so we can see if there's anything wrong with that.

Heres the full command line/output.

P:\22>"D:\VID TOOLS\eac3to\eac3to.exe" "Y:\BDMV\PLAYLIST\00800.mpls" 1) 3: "P:\22\Audio.thd+ac3"
M2TS, 1 video track, 8 audio tracks, 13 subtitle tracks, 1:40:54, 24p /1.001
1: Chapters, 32 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: TrueHD/AC3, English, 7.1 channels, 48kHz
(embedded: AC3 EX, 5.1 channels, 640kbps, 48kHz)
4: AC3 Surround, English, 2.0 channels, 320kbps, 48kHz
5: AC3 EX, Czech, 5.1 channels, 640kbps, 48kHz
6: AC3 EX, Slovak, 5.1 channels, 640kbps, 48kHz
7: AC3 EX, Arabic, 5.1 channels, 640kbps, 48kHz
8: AC3 EX, Russian, 5.1 channels, 640kbps, 48kHz
9: AC3 EX, Ukrainian, 5.1 channels, 640kbps, 48kHz
10: AC3 EX, Croatian, 5.1 channels, 640kbps, 48kHz
11: Subtitle (PGS), English
12: Subtitle (PGS), English
13: Subtitle (PGS), Czech
14: Subtitle (PGS), Slovak
15: Subtitle (PGS), Arabic
16: Subtitle (PGS), Russian
17: Subtitle (PGS), Ukrainian
18: Subtitle (PGS), Croatian
19: Subtitle (PGS), Slovak
20: Subtitle (PGS), Arabic
21: Subtitle (PGS), Ukrainian
22: Subtitle (PGS), Croatian
23: Subtitle (PGS), Czech
a03 AC3 encoding doesn't support back channels. Will mix them into the surround.

a03 Extracting audio track number 3...
a03 Extracting TrueHD stream...
a03 Extracting audio track number 3...
a03 Extracting TrueHD stream...
a03 Decoding with libav/ffmpeg...
a03 Remapping channels...
a03 Mixing surround channels...
a03 Encoding AC3 <640kbps> with libAften...
a03 libav Substream 0 parity check failed
a03 libav Substream 0 checksum failed
a03 libav Substream 0 length mismatch.
a03 The libav decoder reported error -1 while decoding.

[tebasuna51]

I can confirm the issue, I have the same log than lmaolmao:
a03 AC3 encoding doesn't support back channels. Will mix them into the surround.
a03 Extracting audio track number 3...
a03 Extracting audio track number 3...
a03 Extracting TrueHD stream...
a03 Extracting TrueHD stream...
a03 Decoding with libav/ffmpeg...
a03 Remapping channels...
a03 Mixing surround channels...
a03 Encoding AC3 <640kbps> with libAften...
a03 libav Substream 1 parity check failed
a03 libav Substream 1 checksum failed
a03 libav Substream 1 length mismatch.
a03 The libav decoder reported error -1 while decoding.
with this command line:
eac3to.exe "D:\Temp\BRAVE\" 1) 3: "D:\Temp\BRAVE\0_eng3.thd+ac3"

[madshi]

A sample of the Brave's movie m2ts would be helpful.

[lmaolmao]

I'll grab a bit of the first m2ts. And make sure it does show this error.

Edit: Well, if the first m2ts is done directly then it extracts fine......do you still want the sample?

It only does it when the playlist is selected...

[r0lZ]

I have also noticed a very strange thing with the Brave 3D blu-ray. (I don't have the 2D BD to check if it has the same problem.)

Z:\BDMV\PLAYLIST>eac3to 00800.mpls 1)
M2TS, 2 video tracks, 6 audio tracks, 4 subtitle tracks, 1:33:37, 108.607p
1: Chapters, 37 chapters
2: h264/AVC (left eye), 1080p24 /1.001 (16:9)
3: h264/AVC (right eye), 1080p24 /1.001 (16:9)
4: TrueHD/AC3, English, 7.1 channels, 48kHz
(embedded: AC3, 5.1 channels, 640kbps, 48kHz)
5: AC3 Surround, English, 2.0 channels, 320kbps, 48kHz
6: AC3 Surround, English, 2.0 channels, 320kbps, 48kHz
7: AC3, French, 5.1 channels, 512kbps, 48kHz
8: AC3, French, 5.1 channels, 640kbps, 48kHz
9: AC3, Spanish, 5.1 channels, 640kbps, 48kHz
10: Subtitle (PGS), English
11: Subtitle (PGS), English
12: Subtitle (PGS), French
13: Subtitle (PGS), Spanish

As you can see, stream 7 is strange. It has an unusual bit rate, and, as far as I know, that stream does not exist in the BD. There is only one French audio track (listed by eac3to as stream #8). tsMuxeR does NOT show that strange French stream.

When eac3to tries to demux that track, it issues the warning "a07 This track is not clean.", but it continues anyway. The resulting ac3 file plays two times faster than it should in all audio players, and the sound is strange.

[sporic]

i have also noticed a very strange thing with the brave 3d blu-ray. (i don't have the 2d bd to check if it has the same problem.)

z:\bdmv\playlist>eac3to 00800.mpls 1)
m2ts, 2 video tracks, 6 audio tracks, 4 subtitle tracks, 1:33:37, 108.607p
1: Chapters, 37 chapters
2: H264/avc (left eye), 1080p24 /1.001 (16:9)
3: H264/avc (right eye), 1080p24 /1.001 (16:9)
4: Truehd/ac3, english, 7.1 channels, 48khz
(embedded: Ac3, 5.1 channels, 640kbps, 48khz)
5: Ac3 surround, english, 2.0 channels, 320kbps, 48khz
6: Ac3 surround, english, 2.0 channels, 320kbps, 48khz
7: Ac3, french, 5.1 channels, 512kbps, 48khz
8: Ac3, french, 5.1 channels, 640kbps, 48khz
9: Ac3, spanish, 5.1 channels, 640kbps, 48khz
10: Subtitle (pgs), english
11: Subtitle (pgs), english
12: Subtitle (pgs), french
13: Subtitle (pgs), spanish

as you can see, stream 7 is strange. It has an unusual bit rate, and, as far as i know, that stream does not exist in the bd. There is only one french audio track (listed by eac3to as stream #8). Tsmuxer does not show that strange french stream.

When eac3to tries to demux that track, it issues the warning "a07 this track is not clean.", but it continues anyway. The resulting ac3 file plays two times faster than it should in all audio players, and the sound is strange.

cinavia!!! :d

[r0lZ]

Sorry. That might be a noob question, but I don't understand why cinavia should need an additional audio track. The real French audio is in track #8, and if it is protected by cinavia, it is possible to demux it anyway. So, what's the benefit in adding a fake French track?
Also, it seems strange that only the French audio has that additional track, but not the main English or the Spanish audio tracks.
Honestly, I know almost nothing about cinavia, but afaik the protection is simply a watermark, that should not prevent eac3to to demux the track. (Playing it on cinavia protected hardware is another story.)
If I have missed something, can you lead me to a thread with additional info?

[BigPines]

Honestly, I know almost nothing about cinavia, but afaik the protection is simply a watermark, that should not prevent eac3to to demux the track. (Playing it on cinavia protected hardware is another story.)

This is exactly right. I don't think what we are seeing is Cinavia. I think it is some new variant of TrueHD that we have not encountered before.

I will see if I can get a sample together for Madshi.

Mike

[Chumbo]

[EDIT] I moved request to the new bugs/feature requests thread.

[BigPines]

I am posting the bugs and sample files in the new thread: http://forum.doom9.org/showthread.php?t=166487&page=2

Mike

[BigPines]

For anyone interested, I found a bit of a work-around for the Brave/Finding Nemo True-HD seamless branching problem.

I used MakeMkv to transcode the TrueHD 7.1 into FLAC 7.1 and then used eac3to to transcode the FLAC into WAVs. I will probably use this method until there is an official fix for eac3to.

I hope this helps someone else.

Mike

[Sparktank]

For anyone interested, I found a bit of a work-around for the Brave/Finding Nemo True-HD seamless branching problem.

I used MakeMkv to transcode the TrueHD 7.1 into FLAC 7.1 and then used eac3to to transcode the FLAC into WAVs. I will probably use this method until there is an official fix for eac3to.

I hope this helps someone else.

Mike

That's the same solution posted earlier here for using ffmpeg. Just an extra step/program.
MakeMKV has an option to use ffmpeg for audio transcoding.

You forgot to mention that you need to go into options and enable "Advanced options" and tell MMKV where it can find the binary for ffmpeg.
FFmpeg binarys can be found at zeranoe's site.
His site is mentioned on the official ffmpeg website, if most don't know where to find him already.

[BigPines]

That's the same solution posted earlier here for using ffmpeg. Just an extra step/program.
MakeMKV has an option to use ffmpeg for audio transcoding.

You forgot to mention that you need to go into options and enable "Advanced options" and tell MMKV where it can find the binary for ffmpeg.
FFmpeg binarys can be found at zeranoe's site.
His site is mentioned on the official ffmpeg website, if most don't know where to find him already.

You may not have noticed that the solution posted earlier was reported not to work by a follow-up post.

True, MakeMkv uses ffmpeg for the audio transcoding. However, my understanding is MakeMkv comes with a patched version that will not down-convert everything to 16 bits. Admittedly, I don't really know much about the full abilities of ffmpeg. Can it handle seamless branching like MakeMkv can? At any rate, MakeMkv is a valuable program notwithstanding it's reliance on ffmpeg for audio transcoding. It is a worthwhile tool to have in one's arsenal and I choose to use it.

You don't need to tell MakeMkv where the ffmpeg binaries are anymore. That was an older version but you are correct in that advanced options must be enabled to use the FLAC profile.

Just trying to help.

Mike

[Joniii]

maybe i am not making myself clear. This is happening before the -1 error.

with all other truehd discs you can extract a .thd file, the .ac3 core or a .tdh+ac3 file. And it just demuxes it (no encoding).

With BRave and Nemo, you can extract a .thd or the .ac3 core fine. But when extracting the .thd+ac3, eac3to initialises aften to make the ac3 track instead of just demuxing. Which is odd.....

I can confirm I have the same thing with Nemo.


H:\eac3to>eac3to D:\FINDING_NEMO 1) 3: Y:\nemo.thd+ac3
M2TS, 1 video track, 1 audio track, 1 subtitle track, 1:40:54, 24p /1.001
1: Chapters, 32 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: TrueHD/AC3, English, 7.1 channels, 48kHz
(embedded: AC3 EX, 5.1 channels, 640kbps, 48kHz)
4: Subtitle (PGS), English
a03 AC3 encoding doesn't support back channels. Will mix them into the surround.
a03 Extracting audio track number 3...
a03 Extracting TrueHD stream...
a03 Decoding with libav/ffmpeg...
a03 Remapping channels...
a03 Extracting audio track number 3...
a03 Mixing surround channels...
a03 Extracting TrueHD stream...
a03 Encoding AC3 <640kbps> with libAften...
[mlp @ 009c2d10] Substream 0 parity check failed
[mlp @ 009c2d10] Substream 0 checksum failed
[mlp @ 009c2d10] Substream 0 length mismatch.
a03 The libav decoder reported error -1 while decoding.

[lostclusters]

I did a -demux on the Brave 7.1 soundtrack and it seemed to work. But I get intermittent clicks, pops, and sound drop outs in the resulting .mkv. I'll bet some sort of copy protection.

Edit: Might be the source, checking.

[Thunderbolt8]

isnt there any way or hasnt anyone be able to come with some idea how to process THD files with gaps in the meantime? or maybe some idea to get round this problem with the final file still being an in sync THD file? there should be some way, somehow, shouldnt there?

[BigPines]

See my post above. It works fine and everything is in sync.

Mike

[rapscallion]

However, my understanding is MakeMkv comes with a patched version that will not down-convert everything to 16 bits.
You don't need to tell MakeMkv where the ffmpeg binaries are anymore. That was an older version but you are correct in that advanced options must be enabled to use the FLAC profile.

Just trying to help.

Mike
V 1.7.9, which is the latest, there is the option to put in the path to ffmpeg.

There is no "patched" version in the MakeMkv folder that i can see, unless it's mmffmpeg.exe.

Edit: tried the path to mmffmpeg and it worked. I was now able to create the Mkv, with flac audio, and then save the flac to 8 wavs, via eac3to. Finding Nemo Btw, which failed using the straight/unpatched standalone ffmpeg.

[SquallMX]

I have also noticed a very strange thing with the Brave 3D blu-ray. (I don't have the 2D BD to check if it has the same problem.)

Z:\BDMV\PLAYLIST>eac3to 00800.mpls 1)
M2TS, 2 video tracks, 6 audio tracks, 4 subtitle tracks, 1:33:37, 108.607p
1: Chapters, 37 chapters
2: h264/AVC (left eye), 1080p24 /1.001 (16:9)
3: h264/AVC (right eye), 1080p24 /1.001 (16:9)
4: TrueHD/AC3, English, 7.1 channels, 48kHz
(embedded: AC3, 5.1 channels, 640kbps, 48kHz)
5: AC3 Surround, English, 2.0 channels, 320kbps, 48kHz
6: AC3 Surround, English, 2.0 channels, 320kbps, 48kHz
7: AC3, French, 5.1 channels, 512kbps, 48kHz
8: AC3, French, 5.1 channels, 640kbps, 48kHz
9: AC3, Spanish, 5.1 channels, 640kbps, 48kHz
10: Subtitle (PGS), English
11: Subtitle (PGS), English
12: Subtitle (PGS), French
13: Subtitle (PGS), Spanish

As you can see, stream 7 is strange. It has an unusual bit rate, and, as far as I know, that stream does not exist in the BD. There is only one French audio track (listed by eac3to as stream #8). tsMuxeR does NOT show that strange French stream.

When eac3to tries to demux that track, it issues the warning "a07 This track is not clean.", but it continues anyway. The resulting ac3 file plays two times faster than it should in all audio players, and the sound is strange.

There`re 2 French tracks on the Blu-ray, Dolby Digital Plus 7.1 at 896 (as reported by Total Media Theater) and a standard Dolby Digital 5.1 at 640 Kbps (as reported by Total Media Theater). Maybe eac3to is detecting only the core of the 7.1 DD Plus track?

[r0lZ]

Thanks for the info. I suppose you're right, as it detects it as 5.1 @512Kbps. Obviously, it's something that needs to be fixed.

[phate89]

Hi.. I found a bug and i don't know if it's eac3to's fault or (probably) a nero ac3 decoder bug.
I use a lot eac3to to edit audio tracks losslessly and sync with other sources. I also have nero 6 iinstalled and working and i use it to decode ac3 usually. but i recently discover that if i edit an ac3 track (2.0 or 5.1 doesn't matter) the editing is ok, but if i try after to convert the ac3 synced file to wav with nero decoder it looses all the silence i insert in various points in the track... How is that possible? If i set "-libav" all works well, indeed if i downmix the edited 5.1 track to 2.0 it keeps the sync and it works well because it uses by default libav (is this a bug or ment to be libav with downmix?).
It is eac3to or nero related?

[aneurysm]

Just wanted to thank some people here with their fixes / work around's for transcoding THD files with Finding Nemo.
I tried that solution and worked fine.
Extracted THD
ffmpeg THD to flac 7.1
eac3to flac to 5.1 wav files
surcode 5.1 wav files to DTS file
ran through eac3to again to remove zero padding.
Result is perfect.

tnx !! Will try this with Brave too once I get it.

One thing I did (maybe) different from others who can't get it to work, I first used txmuxer to create 1 m2ts file from the playlist.
then used eac3to to extract the thd from that file.

[rapscallion]

I did a very similiar process with Nemo, but am wondering about the resulting file sizes.

Original THD, w/core : 5.1 gb

Extracted thd (no core) : 4.6 gb
ffmpeg THD to flac (w/expected 4 errors) : 2.2 gb
eac3to flac to 8 wavs : 851 mb each
DTS-HD MA suite to DTSenc.dtshd (w/core) 7.1 : 2.6 gb

I have done many THD to DTS-HD conversions in the past and have never seen this big a descrepancy in file sizes.

The DTS result syncs up with the movie just fine, however there is a difference in the bitrates to the original THD track. I imagine it's still lossless, but who knows?

[aneurysm]

I did a very similiar process with Nemo, but am wondering about the resulting file sizes.

Original THD, w/core : 5.1 gb

Extracted thd (no core) : 4.6 gb
ffmpeg THD to flac (w/expected 4 errors) : 2.2 gb
eac3to flac to 8 wavs : 851 mb each
DTS-HD MA suite to DTSenc.dtshd (w/core) 7.1 : 2.6 gb

I have done many THD to DTS-HD conversions in the past and have never seen this big a descrepancy in file sizes.

The DTS result syncs up with the movie just fine, however there is a difference in the bitrates to the original THD track. I imagine it's still lossless, but who knows?

My DTS (non HD) is 1.06 Gb. Sounds great though. Have you tested your file yet on your speakersystem ? How does it sound ?
Btw, I only had 2 errors in ffmpeg

[rapscallion]

No, not yet.

Here's my errors:


Input #0, truehd, from 'nemo.thd':
Duration: N/A, start: 0.000000, bitrate: N/A
Stream #0:0: Audio: truehd, 48000 Hz, 7.1, s32
Output #0, flac, to 'nemo.flac':
Metadata:
encoder : Lavf54.36.100
Stream #0:0: Audio: flac, 48000 Hz, 7.1, s32, 128 kb/s
Stream mapping:
Stream #0:0 -> #0:0 (truehd -> flac)
Press [q] to stop, [?] for help
Lossless check failed - expected 00, calculated f4.s/s
Lossless check failed - expected 00, calculated 65.s/s
End of stream indicated.33:23.61 bitrate=2977.4kbits/s
[truehd @ 024c0900] Lossless check failed - expected 00, calculated f6.
End of stream indicated.40:24.57 bitrate=2976.1kbits/s
[truehd @ 024c0900] Lossless check failed - expected 00, calculated 88.
size= 2195486kB time=01:40:54.04 bitrate=2970.8kbits/s
video:0kB audio:2195477kB subtitle:0 global headers:0kB muxing overhead 0.000367

Edit: Btw, the difference in bitrates that I mentioned above is substantial.

The original THD average BR is 6333 kbps, while the Flac and DTS-HD are 2970 kbps.
I beleive those 4 errors screwed the pooch on this track.

[aneurysm]

No, not yet.

Here's my errors:


Input #0, truehd, from 'nemo.thd':
Duration: N/A, start: 0.000000, bitrate: N/A
Stream #0:0: Audio: truehd, 48000 Hz, 7.1, s32
Output #0, flac, to 'nemo.flac':
Metadata:
encoder : Lavf54.36.100
Stream #0:0: Audio: flac, 48000 Hz, 7.1, s32, 128 kb/s
Stream mapping:
Stream #0:0 -> #0:0 (truehd -> flac)
Press [q] to stop, [?] for help
Lossless check failed - expected 00, calculated f4.s/s
Lossless check failed - expected 00, calculated 65.s/s
End of stream indicated.33:23.61 bitrate=2977.4kbits/s
[truehd @ 024c0900] Lossless check failed - expected 00, calculated f6.
End of stream indicated.40:24.57 bitrate=2976.1kbits/s
[truehd @ 024c0900] Lossless check failed - expected 00, calculated 88.
size= 2195486kB time=01:40:54.04 bitrate=2970.8kbits/s
video:0kB audio:2195477kB subtitle:0 global headers:0kB muxing overhead 0.000367

Edit: Btw, the difference in bitrates that I mentioned above is substantial.

The original THD average BR is 6333 kbps, while the Flac and DTS-HD are 2970 kbps.
I beleive those 4 errors screwed the pooch on this track.

Weird, I only have these 2 :
Lossless check failed - expected 00, calculated f4.s/s
Lossless check failed - expected 00, calculated 65.s/s

and that is indeed a big difference in BR.
for me it's ok since I just needed DTS

[rapscallion]

Weird, I only have these 2 :
Lossless check failed - expected 00, calculated f4.s/s
Lossless check failed - expected 00, calculated 65.s/s

and that is indeed a big difference in BR.
for me it's ok since I just needed DTS
Yes, weird. I ran it twice with the same results.

[SquallMX]

No, not yet.

Here's my errors:


Input #0, truehd, from 'nemo.thd':
Duration: N/A, start: 0.000000, bitrate: N/A
Stream #0:0: Audio: truehd, 48000 Hz, 7.1, s32
Output #0, flac, to 'nemo.flac':
Metadata:
encoder : Lavf54.36.100
Stream #0:0: Audio: flac, 48000 Hz, 7.1, s32, 128 kb/s
Stream mapping:
Stream #0:0 -> #0:0 (truehd -> flac)
Press [q] to stop, [?] for help
Lossless check failed - expected 00, calculated f4.s/s
Lossless check failed - expected 00, calculated 65.s/s
End of stream indicated.33:23.61 bitrate=2977.4kbits/s
[truehd @ 024c0900] Lossless check failed - expected 00, calculated f6.
End of stream indicated.40:24.57 bitrate=2976.1kbits/s
[truehd @ 024c0900] Lossless check failed - expected 00, calculated 88.
size= 2195486kB time=01:40:54.04 bitrate=2970.8kbits/s
video:0kB audio:2195477kB subtitle:0 global headers:0kB muxing overhead 0.000367

Edit: Btw, the difference in bitrates that I mentioned above is substantial.

The original THD average BR is 6333 kbps, while the Flac and DTS-HD are 2970 kbps.
I beleive those 4 errors screwed the pooch on this track.

The original THD is 24 bits, the FLAC/DTS files could be downsampled to 16 bit, usually 16 bits DTS-HD MA files have an average bitrate of 2.5 Mbps. Differences between 24 and 16 bits files are pretty much impossible to hear.

[tebasuna51]

The original THD is 24 bits, the FLAC/DTS files could be downsampled to 16 bit, usually 16 bits DTS-HD MA files have an average bitrate of 2.5 Mbps. Differences between 24 and 16 bits files are pretty much impossible to hear.

Hello, SqualMX!

But this isn't the case, the wav's files have the correct size for a mono, 48 Khz, 24 bit, 1h 43m

Here the strange size is the 4.6 GB for the TrueHD file.
I always see a size for thd between flac and dtshd sizes.
The size and the errors let me suspect for a incorrect extraction.

And, maybe, the wav's have garbage at end because the length of the movie is only 1:40:54, but in sync with the video.
The size of monowav's for 1:40:54 must be 831 MB instead 851.

[aneurysm]

Anyone found a solution/fix for Brave yet ?
indeed lots of errors there, also with ffmpeg thd to flac

EDIT: I continued like yesterday with Nemo, and yes more errors it seems. but the end result is still nice in sync.
kewl :)

[Jan Marijniszoon]

Hello,

I am curious about something...

I decoded an ac3-file to pcm wav with eac3to which used the libav/ffmpeg decoder.
Then i did the same thing in Linux, but there I did it straight with ffmpeg (version 0.10.3).

I compared the outputs in a wave editor and discovered that eac3to produces files with 'larger / louder' waves than ffmpeg.

How can this be while eac3to is also using the ffmpeg decoding system?

Thanks in advance for your insights.

EDIT: this is not due to the removal of dialog normalisation; I already ruled that out.

[kypec]

Perhaps DRC (Dynamic Range Compression) is applied in one and not in the other? Just a wild guess...