eac3to - audio conversion tool - Page 526

Chouonsoku · 27th August 2010, 04:28

Quote:

eac3to v3.24
command line: eac3to2 english.thd+ac3 english.wavs
------------------------------------------------------------------------------
TrueHD/AC3, 5.1 channels, 48kHz
(embedded: AC3, 5.1 channels, 640kbps, 48kHz)
Extracting TrueHD stream...
Decoding with libav/ffmpeg...
Writing WAVs...
[libav] Substream 0 parity check failed <WARNING>
[libav] Substream 0 checksum failed <WARNING>
[libav] Substream 0 length mismatch. <WARNING>
The libav decoder reported error -1 while decoding. <ERROR>
Aborted at file position 262144. <ERROR>

I've been getting this error when trying to split the TrueHD track into wavs using the latest eac3to, whether it's in the M2TS file or demuxed. It's from the Afro Samurai: Resurrection Blu-Ray. This happens when I try to do any conversion with the files, .wavs, .flac, but I can still extract the core AC3 file just fine.

DreckSoft · 28th August 2010, 14:17

Short notice:
There are some kind of MLP files which libav cannot handle: Those with mixed sampling rates (i.e. 96khz for Lf-Rf-C and 48khz for LFE-Ls-Rs). Seems Nero is the only option there. Unfortunately getting the Nero decoder working is ...
It now works after removing Nero and installing the latest Nero Lite 7 version.

Maybe eac3to should check for the mixed sampling rates and select the decoder approriately.

An example for this type of file can be found on the DVD Audio "Nena feat. Nena Live".

If you have any questions about this please write a PM as I'm not reading this thread all the time.

Rumbah · 29th August 2010, 02:51

One thing I just noticed when extracting audio of an avc hd disc to stereo flac (for mp3 encoding) is that even if eac3to notices that a second pass is needed it just continues writing the compressed flac file till the end. After that it gets overwritten with the second pass flac file.
Wouldn't it be faster to abort the encoding and file writing after it discovers that it needs a second pass (especially if the source and target disc are the same)?

TinTime · 29th August 2010, 09:24

Quote:

Originally Posted by Rumbah

One thing I just noticed when extracting audio of an avc hd disc to stereo flac (for mp3 encoding) is that even if eac3to notices that a second pass is needed it just continues writing the compressed flac file till the end. After that it gets overwritten with the second pass flac file.
Wouldn't it be faster to abort the encoding and file writing after it discovers that it needs a second pass (especially if the source and target disc are the same)?

I agree. If I think there's a chance of a second pass then I generally convert to wav as an intermediate file first. I tend to go TrueHD -> wav -> FLAC for example. I find it's the encoding (certainly of FLAC) rather than file writing that takes the time.

tebasuna51 · 29th August 2010, 09:25

Quote:

Originally Posted by Rumbah

...
Wouldn't it be faster to abort the encoding and file writing after it discovers that it needs a second pass (especially if the source and target disc are the same)?

We need continue until the end to know all gaps/ovelaps/overflows before begin the second pass

TinTime · 29th August 2010, 09:37

Quote:

Originally Posted by tebasuna51

We need continue ultil the end to know all gaps/ovelaps/overflows before begin the second pass

He's not talking about aborting all processing though - just "the encoding and file writing".

I admit that I initially read the post exactly the same way as you did

I'd typed out a similar reply to yours before the penny dropped and I realised what Rumbah meant.

Rumbah · 29th August 2010, 12:17

Quote:

Originally Posted by TinTime

He's not talking about aborting all processing though - just "the encoding and file writing".

Exactly. I'm aware that the whole file has to be scanned but if you know that you have to do a second pass there is no need to actually encode and write the first pass results to disc.

video_magic · 30th August 2010, 00:12

1st pass could specify -o NUL , and only write the info to a log file which it needs for the 2nd pass.

2nd pass uses the info from the log file generated from the 1st pass, and this time writes the actual outfile which we want.

It would save some diskdrive wear, be a bit faster, & use less CPU power and generated heat, than writing an output file on the 1st pass for nothing.

Jeff Flowerday · 30th August 2010, 02:14

Any one else seeing this with the Cars Blu-Ray? eac3to 3.24

v02 0:01:15 The source file seems to be damaged (discontinuity).
a04 0:01:15 The source file seems to be damaged (discontinuity).
a03 0:01:15 The source file seems to be damaged (discontinuity).
v02 0:01:15 Detected PTS break, increasing PTS by 41.7ms...
a03 0:01:15 Detected PTS break, increasing PTS by 8ms...
a03 libav Lossless check failed - expected b, calculated 3c
a04 0:01:15 Detected PTS break, increasing PTS by 32.0ms...
a03 0:01:50 The source file seems to be damaged (sync byte missing).
a04 0:01:50 The source file seems to be damaged (sync byte missing).
v02 0:01:51 The source file seems to be damaged (sync byte missing).
v02 0:01:56 The source file seems to be damaged (discontinuity).
a03 0:01:56 The source file seems to be damaged (discontinuity).
a04 0:01:56 The source file seems to be damaged (discontinuity).
a03 libav Lossless check failed - expected ef, calculated d0
v02 0:01:29 The source file seems to be damaged (discontinuity).
a04 0:01:30 The source file seems to be damaged (discontinuity).
a03 0:01:30 The source file seems to be damaged (discontinuity).

Thunderbolt8 · 30th August 2010, 04:02

is it OK if that line "swapping endian..." appears twice?

Code:

eac3to v3.24
command line: eac3to movie 1) 3: movie.pcm
------------------------------------------------------------------------------
M2TS, 1 video track, 2 audio tracks, 1 subtitle track, 1:40:40, 24p /1.001
1: Chapters, 17 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: RAW/PCM, English, 1.0 channels, 24 bits, 48kHz
4: AC3, English, 1.0 channels, 192kbps, 48kHz
5: Subtitle (PGS), English
[a03] Extracting audio track number 3...
[a03] Reading RAW/PCM...
[a03] Swapping endian...
[a03] Swapping endian...
[a03] Creating file "movie.pcm"...
[a03] The original audio track has a constant bit depth of 24 bits.
Video track 2 contains 144816 frames.
eac3to processing took 17 minutes, 51 seconds.
Done.

SC05 · 3rd September 2010, 22:36

I love eac3to, thanks for all the work put into it.

I have one issue which I have never been able to solve, despite numerous attempts and searches.

Two DTS-MA 6.1 soundtracks will not decode properly in eac3to no matter what I have tried (Top Gun and X-Men the Last Stand). I am using eac3to v3.24, Arcsoft DTS decoder v1.1.0.7. It doesn't matter whether I decode straight from the disc, or from the disc to a .dtsma file, then decode. The resultant FLAC file always sounds like a garbled mess (though you can hear the underlying dialog). I have tried doubling the back channel, to no avail.

I though the Arcsoft decoder was supposed to work great with 6.1 and 7.1, as stated in the original post of this thread. What gives? Am i using the wrong version, or do I need to use a different decoder?

Thanks, and I hope I can find some guidance on this issue.

P.S. I have also tried decoding to mono WAVs, and I end up with seven files that all sound identical and garbled (even the LFE, which contains plenty of non-low frequency sound in this case).

tebasuna51 · 4th September 2010, 00:21

It's a know bug of v1.1.0.7, use v1.1.0.0 for DTS-MA 6.1

SC05 · 4th September 2010, 00:37

Thanks for the quick reply. I had no idea about that. I have been pulling my hair out over this one. I'll track down that version and give it a go.

SC05 · 4th September 2010, 02:08

Wow, it works perfectly now, thanks again!

yesgrey · 4th September 2010, 11:18

madshi,
Recently I noticed that when demuxing all files to the same disk the video file is created with hundreds of fragments, even though the disk has been defragged and lots of empty space available. Since I have 3 hard disks, and I only extract a few streams (original audio, video, chapters and 1 or 2 subs), I thought that I might be able to speed up the processing by writing the demuxed files to separate disks. I've created a 256 MB ram disk for putting the smaller files, and sent the video and audio for different hard disks. It didn't seem to have resulted, because the processing time increased by 50% (different BR), but on the other hand the fragmentation was smaller. Instead of 137 fragments I only got 29. The first case was a demuxed mpeg2 stream, and the second was a H264 stream to mkv file. The curious thing is that only the video file is fragmented, so would it be possible for you to avoid the fragmentation? For example, by first allocating the full size of the file, or any other method? I think this would be a nice feature because besides the speedup it would also help reducing the stress on the hard disks...

laserfan · 4th September 2010, 15:40

Quote:

Originally Posted by tebasuna51

It's a know bug of v1.1.0.7, use v1.1.0.0 for DTS-MA 6.1

Do you (or anyone) know:

1. Was 1.1.0.0 the version with v2.0 of TMT? I have v2 but am using 3.0 now.

2. Is it as simple as overwriting the 1.1.0.7 dll (mine's in my eac3to dir)

3. Was there a "known bug" in 1.1.0.0 that we exchange for when we revert from .7 to .0

TIA

tebasuna51 · 4th September 2010, 18:08

1) ArcSoft.TotalMedia.Theatre.v2.1.6.129

2) If you have the full TMT 3.0 installed maybe you can't use v1.0.0.0.
If you have only some files in eac3to folder:
- unregister ASAudioHD.ax from v1.1.0.7 (maybe not needed but is a good method)
- replace the files
- register the ASAudioHD.ax from v1.1.0.0

3) I don't know bugs of v1.1.0.0 working with eac3to

laserfan · 4th September 2010, 18:16

Quote:

Originally Posted by tebasuna51

1) ArcSoft.TotalMedia.Theatre.v2.1.6.129

2) If you have the full TMT 3.0 installed maybe you can't use v1.0.0.0.
If you have only some files in eac3to folder:
- unregister ASAudioHD.ax from v1.1.0.7 (maybe not needed but is a good method)
- replace the files
- register the ASAudioHD.ax from v1.1.0.0

3) I don't know bugs of v1.1.0.0 working with eac3to

Thanks! I will see how easy/hard this and report back.

5th September 2010, 11:21

Quote:

Originally Posted by laserfan

1. Was 1.1.0.0 the version with v2.0 of TMT? I have v2 but am using 3.0 now.

Version 1.1.0.0 was the absolute final version for the v2.x series (the "Update" files are still in the TMT archive) ..

Quote:

2. Is it as simple as overwriting the 1.1.0.7 dll (mine's in my eac3to dir)

Yes, don't even bother with any other files, just overwrite "dtsdecoderdll.dll" with the older version (or rename 1.1.0.7 and copy 1.1.0.0 into same directory) ...

Quote:

3. Was there a "known bug" in 1.1.0.0 that we exchange for when we revert from .7 to .0

Doesn't seem to be, but changelogs don't appear for these files, so very difficult to assess what the actual differences are ...

7ek

laserfan · 5th September 2010, 16:19

Quote:

Originally Posted by 7ekno

Version 1.1.0.0 was the absolute final version for the v2.x series... just overwrite "dtsdecoderdll.dll" with the older version (or rename 1.1.0.7 and copy 1.1.0.0 into same directory) ...

Thanks 7ekno. I found it easily and just copied it over and it works.

30th August 2010, 00:12	#10508 \| Link
video_magic Registered User Join Date: Jan 2005 Posts: 368	1st pass could specify -o NUL , and only write the info to a log file which it needs for the 2nd pass. 2nd pass uses the info from the log file generated from the 1st pass, and this time writes the actual outfile which we want. It would save some diskdrive wear, be a bit faster, & use less CPU power and generated heat, than writing an output file on the 1st pass for nothing. __________________ Thankyou!, I am grateful for any help

3rd September 2010, 22:36	#10511 \| Link
SC05 Registered User Join Date: Jun 2009 Posts: 3	I love eac3to, thanks for all the work put into it. I have one issue which I have never been able to solve, despite numerous attempts and searches. Two DTS-MA 6.1 soundtracks will not decode properly in eac3to no matter what I have tried (Top Gun and X-Men the Last Stand). I am using eac3to v3.24, Arcsoft DTS decoder v1.1.0.7. It doesn't matter whether I decode straight from the disc, or from the disc to a .dtsma file, then decode. The resultant FLAC file always sounds like a garbled mess (though you can hear the underlying dialog). I have tried doubling the back channel, to no avail. I though the Arcsoft decoder was supposed to work great with 6.1 and 7.1, as stated in the original post of this thread. What gives? Am i using the wrong version, or do I need to use a different decoder? Thanks, and I hope I can find some guidance on this issue. P.S. I have also tried decoding to mono WAVs, and I end up with seven files that all sound identical and garbled (even the LFE, which contains plenty of non-low frequency sound in this case). Last edited by SC05; 3rd September 2010 at 22:53.

4th September 2010, 00:21	#10512 \| Link
tebasuna51 Moderator Join Date: Feb 2005 Location: Spain Posts: 6,915	It's a know bug of v1.1.0.7, use v1.1.0.0 for DTS-MA 6.1 __________________ BeHappy, AviSynth audio transcoder.

4th September 2010, 18:08	#10517 \| Link
tebasuna51 Moderator Join Date: Feb 2005 Location: Spain Posts: 6,915	1) ArcSoft.TotalMedia.Theatre.v2.1.6.129 2) If you have the full TMT 3.0 installed maybe you can't use v1.0.0.0. If you have only some files in eac3to folder: - unregister ASAudioHD.ax from v1.1.0.7 (maybe not needed but is a good method) - replace the files - register the ASAudioHD.ax from v1.1.0.0 3) I don't know bugs of v1.1.0.0 working with eac3to __________________ BeHappy, AviSynth audio transcoder.

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

28th August 2010, 14:17	#10502 \| Link
DreckSoft Registered User Join Date: Mar 2002 Posts: 117	Short notice: There are some kind of MLP files which libav cannot handle: Those with mixed sampling rates (i.e. 96khz for Lf-Rf-C and 48khz for LFE-Ls-Rs). Seems Nero is the only option there. Unfortunately getting the Nero decoder working is ... It now works after removing Nero and installing the latest Nero Lite 7 version. Maybe eac3to should check for the mixed sampling rates and select the decoder approriately. An example for this type of file can be found on the DVD Audio "Nena feat. Nena Live". If you have any questions about this please write a PM as I'm not reading this thread all the time.

29th August 2010, 02:51	#10503 \| Link
Rumbah Registered User Join Date: Mar 2003 Posts: 480	One thing I just noticed when extracting audio of an avc hd disc to stereo flac (for mp3 encoding) is that even if eac3to notices that a second pass is needed it just continues writing the compressed flac file till the end. After that it gets overwritten with the second pass flac file. Wouldn't it be faster to abort the encoding and file writing after it discovers that it needs a second pass (especially if the source and target disc are the same)?

30th August 2010, 02:14	#10509 \| Link
Jeff Flowerday Registered User Join Date: Aug 2008 Location: Calgary, AB Posts: 150	Any one else seeing this with the Cars Blu-Ray? eac3to 3.24 v02 0:01:15 The source file seems to be damaged (discontinuity). a04 0:01:15 The source file seems to be damaged (discontinuity). a03 0:01:15 The source file seems to be damaged (discontinuity). v02 0:01:15 Detected PTS break, increasing PTS by 41.7ms... a03 0:01:15 Detected PTS break, increasing PTS by 8ms... a03 libav Lossless check failed - expected b, calculated 3c a04 0:01:15 Detected PTS break, increasing PTS by 32.0ms... a03 0:01:50 The source file seems to be damaged (sync byte missing). a04 0:01:50 The source file seems to be damaged (sync byte missing). v02 0:01:51 The source file seems to be damaged (sync byte missing). v02 0:01:56 The source file seems to be damaged (discontinuity). a03 0:01:56 The source file seems to be damaged (discontinuity). a04 0:01:56 The source file seems to be damaged (discontinuity). a03 libav Lossless check failed - expected ef, calculated d0 v02 0:01:29 The source file seems to be damaged (discontinuity). a04 0:01:30 The source file seems to be damaged (discontinuity). a03 0:01:30 The source file seems to be damaged (discontinuity).

4th September 2010, 00:37	#10513 \| Link
SC05 Registered User Join Date: Jun 2009 Posts: 3	Thanks for the quick reply. I had no idea about that. I have been pulling my hair out over this one. I'll track down that version and give it a go.

4th September 2010, 02:08	#10514 \| Link
SC05 Registered User Join Date: Jun 2009 Posts: 3	Wow, it works perfectly now, thanks again!

4th September 2010, 11:18	#10515 \| Link
yesgrey Registered User Join Date: Sep 2004 Posts: 1,295	madshi, Recently I noticed that when demuxing all files to the same disk the video file is created with hundreds of fragments, even though the disk has been defragged and lots of empty space available. Since I have 3 hard disks, and I only extract a few streams (original audio, video, chapters and 1 or 2 subs), I thought that I might be able to speed up the processing by writing the demuxed files to separate disks. I've created a 256 MB ram disk for putting the smaller files, and sent the video and audio for different hard disks. It didn't seem to have resulted, because the processing time increased by 50% (different BR), but on the other hand the fragmentation was smaller. Instead of 137 fragments I only got 29. The first case was a demuxed mpeg2 stream, and the second was a H264 stream to mkv file. The curious thing is that only the video file is fragmented, so would it be possible for you to avoid the fragmentation? For example, by first allocating the full size of the file, or any other method? I think this would be a nice feature because besides the speedup it would also help reducing the stress on the hard disks...