eac3to - audio conversion tool

[lchiu7]

Been trying to use a program tonmt which is a wrapper to transform BD and HD-DVD titles into a format that can be played by the Popcorn Hour. A critical component is eac3to. I am new to this so bear with me. Running tonmt on the HD-DVD title Shooter, it seems to fail on eac3to and since there are no java errors I wonder it it's a problem with either my configuration (Vista 32 SP1) or with eac3to (or something else). The HD-DVD was ripped to my local HD with AnyDVD. No errors occurred in the rip and all previous steps including merging the EVO and pulldown seemed to complete okay

This is my eac3to status log

eac3to (v3.05) is up to date
Nero Audio Decoder (Nero 7) works fine
ArcSoft DTS Decoder doesn't seem to be installed
http://www.arcsoft.com/products/totalmediatheatre
Sonic Audio Decoder (3.5.0.0) doesn't seem to be installed
Haali Matroska Muxer (2007-06-03) is installed
There's a new version (2009-01-11) available
http://haali.net/mkv
Nero AAC Encoder could not be located
http://www.nero.com/eng/nero-aac-codec.html
Copy NeroAacEnc.exe to the eac3to or to the Windows folder.
Surcode DTS Encoder doesn't seem to be installed
http://www.surcode.com
MkvToolnix (2.2.0.0, 2008-03-04) is installed
There's a new release version (2.4.1.0) available
http://www.bunkus.org/videotools/mkvtoolnix
There's a new beta version (2.4.2.0, 2009-01-18) available
http://www.bunkus.org/videotools/mkvtoolnix/win32/pre

However when eac3to runs on the eac3 file created by tonmt the following error occurs

eac3to v3.05
command line: C:\apps\ToNMT_5.1.0\eac3to\eac3to.exe C:\Temp\HDDVD_c0.eac3 C:\Temp\HDDVD.AC3
------------------------------------------------------------------------------
E-AC3, 5.1 channels, 2:05:44, 1536kbps, 48khz, dialnorm: -27dB
Disabling DRC for Nero (E-)AC3 decoding...
Removing E-AC3 dialog normalization...
Decoding with DirectShow (Nero Audio Decoder 2)...
Aborted at file position 1448429568. <ERROR>

Out of interest tried running an earlier version of eac3to. Not sure which version since -test doesn't provide version information but dated Jan 2008

This runs to completion but produces no output file

No idea what to do next? Any assistance appreciated

Thanks

[lexor]

there's no padding! the resultant flac tracks are 24bit. i know eac3to removes zero-bytes if there's only 16bits of valid information but these are all tracks that have full 24 valid bits
You should've mentioned that, seeing how the log does not.

If you did, it would've sounded like a bug report and not like you asking for someone to explain to you the meaning of those lines.

[shambles]

i should've phrased the first post better, yes, but the log in the second post does clearly show that the audio track has a constant bit depth of 24 bits

[Sharc]

When I use -speedup it seems that eac3to always assumes 23.976fps for the audio source.
How can I speedup 24.0000 fps (film) => 25 fps?

[lexor]

i should've phrased the first post better, yes, but the log in the second post does clearly show that the audio track has a constant bit depth of 24 bits

huh? no it does not. It shows that original track (TrueHD, 3: selection) has 24bits. Which as madshi explained and I elaborated it always would. The log says nothing about output bitdepth of the flac file.

[shambles]

when eac3to reports "original audio track has" this or that bit depth after processing an audio track, it shows the result of the bit depth analysation. it's always the number of valid bits.

for example, a 16bit truehd track:

eac3to v3.05
command line: eac3to G:\BDROM 1) 3: f:\amelie.flac
------------------------------------------------------------------------------
M2TS, 1 video track, 3 audio tracks, 4 subtitle tracks, 2:01:35, 24p /1.001
1: Chapters, 12 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: TrueHD/AC3, French, 5.1 channels, 48khz
(embedded: AC3, 5.1 channels, 640kbps, 48khz)
4: RAW/PCM, Japanese, 2.0 channels, 16 bits, 48khz
5: AC3, French, 2.0 channels, 192kbps, 48khz
6: Subtitle (PGS), Japanese
7: Subtitle (PGS), French
8: Subtitle (PGS), Japanese
9: Subtitle (PGS), Japanese
[a03] Extracting audio track number 3...
[a03] Extracting TrueHD stream...
[a03] Decoding with libav/ffmpeg...
[a03] Encoding FLAC with libFlac...
[a03] Creating file "f:\amelie.flac"...
[a03] The original audio track has a constant bit depth of 16 bits.
[a03] Superfluous zero bytes detected, will be stripped in 2nd pass.
[a03] Starting 2nd pass...
[a03] Decoding FLAC...
[a03] Reducing depth from 24 to 16 bits...
[a03] Encoding FLAC with libFlac...
[a03] Creating file "f:\amelie.flac"...
[a03] The processed audio track has a constant bit depth of 16 bits.
Video track 2 contains 174912 frames.
eac3to processing took 20 minutes, 49 seconds.
Done.

[lexor]

hmm, does sound like something is wrong, so we'll have to wait for madshi to look into it. It could still be the case that the second pass is unrelated to the bitdepth stuff (maybe it's one of those branching or other special structures on the disk) that require second pass to get the timings right.

so it could be just bug in logging.

[madshi]

oh right. but then why is this happening:

[a03] The original audio track has a constant bit depth of 24 bits.
[a03] Superfluous zero bytes detected, will be stripped in 2nd pass.
Yeah, that is weird. The track can either have a constant bit depth of 24 bits or there can be zero bytes, but not both at the same time. Will have to check that...

I had the chance to demux 3 BD movies last night, and I have attached their logs.

As you can see the processing took anywhere from 1:03:00 to 1:44:00 which is much better than v3.04, but not as good a v2.87. As previously discussed via email, v2.87 performance was fast enough demux a 1:45 hour movie in 27 minutes.

What size blocks did you use in v2.87? Was it 4K blocks? Maybe it's better to go back to that size or even try 8K blocks?
I've tested the best speed with my specific Blu-Ray drive and it was with 2K blocks. v2.87 used 64K blocks, IIRC, but it performed noticably worse on my PC. So maybe the optimal block read size depends on the drive model? Uh, that's ugly. Will have to think about how to solve that.

Have you done that other test I asked you to do: Namely ripping the movie to harddisk first and then comparing v2.87 vs. v3.05 when running on the harddisk folder? I think v3.05 should be noticably faster in that situation...

This option doesn't exist anymore: may I ask what did it "technically" do?
Why would you want to know what an old option did, which doesn't even exist, anymore?

The clipping MP2 is uploading. I re-verified that both MPG -> MP2 -> AC3 and MPG -> AC3 both produce clipping, but MPG -> MP2 -> 32float WAV (with Foobar) > AC3 (with eac3to) works fine.
Thanks, I'll check this out.

Been trying to use a program tonmt which is a wrapper to transform BD and HD-DVD titles into a format that can be played by the Popcorn Hour. A critical component is eac3to. I am new to this so bear with me. Running tonmt on the HD-DVD title Shooter, it seems to fail on eac3to and since there are no java errors I wonder it it's a problem with either my configuration (Vista 32 SP1) or with eac3to (or something else). The HD-DVD was ripped to my local HD with AnyDVD. No errors occurred in the rip and all previous steps including merging the EVO and pulldown seemed to complete okay

Out of interest tried running an earlier version of eac3to. Not sure which version since -test doesn't provide version information but dated Jan 2008

This runs to completion but produces no output file

No idea what to do next? Any assistance appreciated
Please try using "-libav" to use the libav decoder instead of Nero. Maybe that helps? How big is that E-AC3 track? Can you reproduce the problem with a small sample of the track? If so, it would be nice if you could upload it for me to test...

When I use -speedup it seems that eac3to always assumes 23.976fps for the audio source.
How can I speedup 24.0000 fps (film) => 25 fps?
When the audio is in a container eac3to automatically applies 24.000 -> 25.000 speedup. When the audio is demuxed, eac3to cannot possibly know which FPS the audio has, so it assumes the usual case of 23.976 -> 25.000. You can tell eac3to which FPS the demuxed audio file has by using the parameter "-24.000". So the command line would be: "eac3to source.whatever dest.whatever -24.000 -speedup".

[Sharc]

All clear now. Thanks madshi.

[nautilus7]

TrueHD sample (http://www.sendspace.com/file/3vfsp7) that shows same behavior. Maybe it happens with all real 24 bit tracks...

eac3to aaa.thd aaa.flac
TrueHD, 5.1 channels, 48khz
Decoding with libav/ffmpeg...
Encoding FLAC with libFlac...
Creating file "aaa.flac"...
The original audio track has a constant bit depth of 24 bits.
Superfluous zero bytes detected, will be stripped in 2nd pass.
Starting 2nd pass...
Decoding FLAC...
Encoding FLAC with libFlac...
Creating file "aaa.flac"...
eac3to processing took 9 seconds.
Done.

eac3to aaa.flac
FLAC, 5.1 channels, 0:00:36, 24 bits, 2051kbps, 48khz

[Thunderbolt8]

might be only a display bug. the trueHD track for the zodiac BD is 3,43 GB, and the constant 24-bit track with then supposed to be superflous zero bytes still has 3,23 GB of size. should be less in case they were really stripped. mediainfo also tells VALID_BITS: 24 for that track.

[shambles]

i've ripped ~30 truehd tracks to flac in the last couple days and it always does the 2nd pass whether the tracks have 24 valid bits or not. with 24bit tracks it doesn't seem to remove anything tho, but it does make the processing take more time obviously.

[nautilus7]

Can you name some movies to confirm whether they are true 24bit? For example, the sample i posted above is from Planet Terror.

Just curious...

EDIT: I can confirm about Godfather 1,2,3. I don't remember/know about the others. So it seems it's a general bug.

[shambles]

planet terror yes, and lately i also ripped godfather 1&2 (part3 probably also had 24bit track but didn't rip that yet), dexter season 1 (all 12 eps), spider-man 3 and lucky number slevin usa release and they all have full 24bit truehd tracks

[bigdog660]

Have you done that other test I asked you to do: Namely ripping the movie to harddisk first and then comparing v2.87 vs. v3.05 when running on the harddisk folder? I think v3.05 should be noticably faster in that situation...

I did that test for v3.04: "After dumping the ISO to the HDD using AnyDVD HD, and loading the ISO using Virtual CloneDrive, eac3to 3.04 only took 15 minutes and 56 seconds! And that was reading and writing to the same drive (D:\)! Also the command eac3to J:\ and eac3to J:\ 1) were extremely fast executing."

I will now do the same test for v2.87 and v3.05 plus I will give you data for a rip from the BD drive just for additional info.

[73ChargerFan]

I've tested the best speed with my specific Blu-Ray drive and it was with 2K blocks. v2.87 used 64K blocks, IIRC, but it performed noticably worse on my PC. So maybe the optimal block read size depends on the drive model? Uh, that's ugly. Will have to think about how to solve that.

I can think of two ways:

1 - post a utility that users can run to benchmark the read speed of their bd or bd/hd-dvd drive, and which when run will email to a dedicated address the results, including drive model & os. Evaluate and include in the program.

2 - include the benchmark routine in eac3to, it can be run by a command line switch and store the value in the registry or in an .ini file. When eac3to runs, it will use a default value unless it the .ini file is present, in which case it loads the value from there.

[kypec]

I can think of two ways:

1 - post a utility that users can run to benchmark the read speed of their bd or bd/hd-dvd drive, and which when run will email to a dedicated address the results, including drive model & os. Evaluate and include in the program.

2 - include the benchmark routine in eac3to, it can be run by a command line switch and store the value in the registry or in an .ini file. When eac3to runs, it will use a default value unless it the .ini file is present, in which case it loads the value from there.:eek:
Sounds like too sophisticated solution for such sleek CLI application to me.
Why not just introduce another option switch -buffer with variable parameter for size in kB, something like -buffer2 / -buffer16 / -buffer64 / -buffer256. Any experienced user can run few tests first in order to benchmark his BD/HDD drive and will use the best option always later on. In case of missing -buffer? switch defaults will be used of course though they may perform worse on user's system. That's the beauty of CLI which should not be mangled by INI or REGISTRY writing whatsoever.

[73ChargerFan]

What is wrong with an ini file? He's already got a directory full of DLLs and a PlugIns directory.

[madshi]

Guys, you don't really need to discuss how I should implement something. :) I'll make up my own solution, anyway...

[kypec]

What is wrong with an ini file? He's already got a directory full of DLLs and a PlugIns directory.
1. All those DLLs and Plugins are to be READ ONLY
2. Update process is much easier -> just overwrite target files with the new ones and you're done, there's no need to keep INI file and watch for its compatibility across future versions of eac3to
3. Implementation of INI parser into existing source code means much more work than adding one more CLI switch
4. Unless there is significant amount of configuration options needed for application then it's better to stay away from INI/registry altogether
5. GUI add-ons can easily adopt any new CLI option and keep it along with many other settings in their own INI files if necessary

[lchiu7]

Please try using "-libav" to use the libav decoder instead of Nero. Maybe that helps? How big is that E-AC3 track? Can you reproduce the problem with a small sample of the track? If so, it would be nice if you could upload it for me to test...
..p".

-libav works fine so it must be my Nero 7 installation. Since everybody seems to be having no problems I don't think it's a bug in eac3to. The eac3 file is 1.2G. Happy to upload it for testing if you can tell me what tool I could use to cut it down to size

[edit]

Just realised that it dies a fair way into the eac3 file so would be hard to provide a piece to test. Since a member on another BBS ripped the same title with no problems and -libav works, I am going to put this done to a bad Nero 7 installation rather than any inherent problem with eac3to (which is a great tool BTW). Thanks for looking

[bigdog660]

Hello Madshi! Finally, here are my test results for all three versions.

Source: Hellboy (2:12:29)

Rip from HDD Folder C: to HDD D: using v2.87

eac3to v2.87
command line: "D:\HDDVDTL\eac3to.exe" "C:\TEMP\HELLBOY\BDMV\STREAM\00090.m2ts" 2: "D:\HELLBOY\feature.mkv" 1: "D:\HELLBOY\chapters.txt" 4: "D:\HELLBOY\feature.ac3"
------------------------------------------------------------------------------
M2TS, 1 video track, 4 audio tracks, 7 subtitle tracks, 2:12:29, 24p /1.001
1: Chapters, 16 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: RAW/PCM, 5.1 channels, 16 bits, 48khz
4: AC3, 5.1 channels, 640kbps, 48khz
5: AC3, 5.1 channels, 640kbps, 48khz, dialnorm: -29dB
6: AC3 Surround, 2.0 channels, 192kbps, 48khz, dialnorm: -26dB
7: Subtitle (PGS)
8: Subtitle (PGS)
9: Subtitle (PGS)
10: Subtitle (PGS)
11: Subtitle (PGS)
12: Subtitle (PGS)
13: Subtitle (PGS)
Creating file "D:\HELLBOY\chapters.txt"...
[v02] Extracting video track number 2...
[a04] Extracting audio track number 4...
[v02] Muxing video to Matroska...
[a04] Creating file "D:\HELLBOY\feature.ac3"...
Added fps value to MKV header.
Video track 2 contains 190583 frames.
eac3to processing took 39 minutes, 18 seconds.
Done.

Rip from Virtual Drive K: to HDD D: using v2.87

eac3to v2.87
command line: "D:\HDDVDTL\eac3to.exe" "K:\" 1) 2: "D:\HELLBOY\feature.mkv" 1: "D:\HELLBOY\chapters.txt" 4: "D:\HELLBOY\feature.ac3"
------------------------------------------------------------------------------
M2TS, 1 video track, 4 audio tracks, 7 subtitle tracks, 2:12:29
1: Chapters, 16 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: RAW/PCM, English, 5.1 channels, 16 bits, 48khz
4: AC3, English, 5.1 channels, 640kbps, 48khz
5: AC3, Thai, 5.1 channels, 640kbps, 48khz, dialnorm: -29dB
6: AC3 Surround, English, 2.0 channels, 192kbps, 48khz, dialnorm: -26dB
7: Subtitle (PGS), English
8: Subtitle (PGS), English
9: Subtitle (PGS), Chinese
10: Subtitle (PGS), Chinese
11: Subtitle (PGS), Portuguese
12: Subtitle (PGS), Spanish
13: Subtitle (PGS), Thai
Creating file "D:\HELLBOY\chapters.txt"...
[v02] Extracting video track number 2...
[a04] Extracting audio track number 4...
[v02] Muxing video to Matroska...
[a04] Creating file "D:\HELLBOY\feature.ac3"...
Added fps value to MKV header.
Video track 2 contains 190583 frames.
eac3to processing took 37 minutes, 13 seconds.
Done.


Rip from BD Drive E: to HDD D: using v2.87

eac3to v2.87
command line: "D:\HDDVDTL\eac3to.exe" "E:\" 1) 2: "D:\HELLBOY\New Folder\feature.mkv" 1: "D:\HELLBOY\New Folder\chapters.txt" 4: "D:\HELLBOY\New Folder\feature.ac3"
------------------------------------------------------------------------------
M2TS, 1 video track, 4 audio tracks, 7 subtitle tracks, 2:12:29
1: Chapters, 16 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: RAW/PCM, English, 5.1 channels, 16 bits, 48khz
4: AC3, English, 5.1 channels, 640kbps, 48khz
5: AC3, Thai, 5.1 channels, 640kbps, 48khz, dialnorm: -29dB
6: AC3 Surround, English, 2.0 channels, 192kbps, 48khz, dialnorm: -26dB
7: Subtitle (PGS), English
8: Subtitle (PGS), English
9: Subtitle (PGS), Chinese
10: Subtitle (PGS), Chinese
11: Subtitle (PGS), Portuguese
12: Subtitle (PGS), Spanish
13: Subtitle (PGS), Thai
Creating file "D:\HELLBOY\New Folder\chapters.txt"...
[v02] Extracting video track number 2...
[a04] Extracting audio track number 4...
[v02] Muxing video to Matroska...
[a04] Creating file "D:\HELLBOY\New Folder\feature.ac3"...
Added fps value to MKV header.
Video track 2 contains 190583 frames.
eac3to processing took 58 minutes, 33 seconds.
Done.

Rip from HDD Folder C: to HDD D: using v3.04

eac3to v3.04
command line: "D:\HDDVDTL\eac3to.exe" "C:\TEMP\HELLBOY\BDMV\STREAM\00090.m2ts" 2: "D:\HELLBOY\feature.mkv" 1: "D:\HELLBOY\chapters.txt" 4: "D:\HELLBOY\feature.ac3"
------------------------------------------------------------------------------
M2TS, 1 video track, 4 audio tracks, 7 subtitle tracks, 2:12:29, 24p /1.001
1: Chapters, 16 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: RAW/PCM, 5.1 channels, 16 bits, 48khz
4: AC3, 5.1 channels, 640kbps, 48khz
5: AC3, 5.1 channels, 640kbps, 48khz, dialnorm: -29dB
6: AC3 Surround, 2.0 channels, 192kbps, 48khz, dialnorm: -26dB
7: Subtitle (PGS)
8: Subtitle (PGS)
9: Subtitle (PGS)
10: Subtitle (PGS)
11: Subtitle (PGS)
12: Subtitle (PGS)
13: Subtitle (PGS)
Creating file "D:\HELLBOY\chapters.txt"...
[v02] Extracting video track number 2...
[a04] Extracting audio track number 4...
[v02] Muxing video to Matroska...
[a04] Creating file "D:\HELLBOY\feature.ac3"...
Added fps value to MKV header.
Video track 2 contains 190583 frames.
eac3to processing took 22 minutes, 52 seconds.
Done.

Rip from Virtual Drive K: to HDD D: using v3.04

eac3to v3.04
command line: "D:\HDDVDTL\eac3to.exe" "K:\" 1) 2: "D:\HELLBOY\feature.mkv" 1: "D:\HELLBOY\chapters.txt" 4: "D:\HELLBOY\feature.ac3"
------------------------------------------------------------------------------
M2TS, 1 video track, 4 audio tracks, 7 subtitle tracks, 2:12:29
1: Chapters, 16 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: RAW/PCM, English, 5.1 channels, 16 bits, 48khz
4: AC3, English, 5.1 channels, 640kbps, 48khz
5: AC3, Thai, 5.1 channels, 640kbps, 48khz, dialnorm: -29dB
6: AC3 Surround, English, 2.0 channels, 192kbps, 48khz, dialnorm: -26dB
7: Subtitle (PGS), English
8: Subtitle (PGS), English
9: Subtitle (PGS), Chinese
10: Subtitle (PGS), Chinese
11: Subtitle (PGS), Portuguese
12: Subtitle (PGS), Spanish
13: Subtitle (PGS), Thai
Creating file "D:\HELLBOY\chapters.txt"...
[v02] Extracting video track number 2...
[a04] Extracting audio track number 4...
[v02] Muxing video to Matroska...
[a04] Creating file "D:\HELLBOY\feature.ac3"...
Added fps value to MKV header.
Video track 2 contains 190583 frames.
eac3to processing took 20 minutes, 56 seconds.
Done.


Rip from BD Drive E: to HDD D: using v3.04

eac3to v3.04
command line: "D:\HDDVDTL\eac3to.exe" "E:\" 1) 2: "D:\HELLBOY\New Folder\feature.mkv" 1: "D:\HELLBOY\New Folder\chapters.txt" 4: "D:\HELLBOY\New Folder\feature.ac3"
------------------------------------------------------------------------------
M2TS, 1 video track, 4 audio tracks, 7 subtitle tracks, 2:12:29
1: Chapters, 16 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: RAW/PCM, English, 5.1 channels, 16 bits, 48khz
4: AC3, English, 5.1 channels, 640kbps, 48khz
5: AC3, Thai, 5.1 channels, 640kbps, 48khz, dialnorm: -29dB
6: AC3 Surround, English, 2.0 channels, 192kbps, 48khz, dialnorm: -26dB
7: Subtitle (PGS), English
8: Subtitle (PGS), English
9: Subtitle (PGS), Chinese
10: Subtitle (PGS), Chinese
11: Subtitle (PGS), Portuguese
12: Subtitle (PGS), Spanish
13: Subtitle (PGS), Thai
Creating file "D:\HELLBOY\New Folder\chapters.txt"...
[v02] Extracting video track number 2...
[a04] Extracting audio track number 4...
[v02] Muxing video to Matroska...
[a04] Creating file "D:\HELLBOY\New Folder\feature.ac3"...
Added fps value to MKV header.
Video track 2 contains 190583 frames.
eac3to processing took 4 hours, 15 minutes.
Done.

Rip from HDD Folder C: to HDD D: using v3.05

eac3to v3.05
command line: "D:\HDDVDTL\eac3to.exe" "C:\TEMP\HELLBOY\BDMV\STREAM\00090.m2ts" 2: "D:\HELLBOY\feature.mkv" 1: "D:\HELLBOY\chapters.txt" 4: "D:\HELLBOY\feature.ac3"
------------------------------------------------------------------------------
M2TS, 1 video track, 4 audio tracks, 7 subtitle tracks, 2:12:29, 24p /1.001
1: Chapters, 16 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: RAW/PCM, 5.1 channels, 16 bits, 48khz
4: AC3, 5.1 channels, 640kbps, 48khz
5: AC3, 5.1 channels, 640kbps, 48khz, dialnorm: -29dB
6: AC3 Surround, 2.0 channels, 192kbps, 48khz, dialnorm: -26dB
7: Subtitle (PGS)
8: Subtitle (PGS)
9: Subtitle (PGS)
10: Subtitle (PGS)
11: Subtitle (PGS)
12: Subtitle (PGS)
13: Subtitle (PGS)
Creating file "D:\HELLBOY\chapters.txt"...
[v02] Extracting video track number 2...
[a04] Extracting audio track number 4...
[v02] Muxing video to Matroska...
[a04] Creating file "D:\HELLBOY\feature.ac3"...
Added fps value to MKV header.
Video track 2 contains 190583 frames.
eac3to processing took 24 minutes, 46 seconds.
Done.

Rip from Virtual Drive K: to HDD D: using v3.05

eac3to v3.05
command line: "D:\HDDVDTL\eac3to.exe" "K:\" 1) 2: "D:\HELLBOY\feature.mkv" 1: "D:\HELLBOY\chapters.txt" 4: "D:\HELLBOY\feature.ac3"
------------------------------------------------------------------------------
M2TS, 1 video track, 4 audio tracks, 7 subtitle tracks, 2:12:29
1: Chapters, 16 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: RAW/PCM, English, 5.1 channels, 16 bits, 48khz
4: AC3, English, 5.1 channels, 640kbps, 48khz
5: AC3, Thai, 5.1 channels, 640kbps, 48khz, dialnorm: -29dB
6: AC3 Surround, English, 2.0 channels, 192kbps, 48khz, dialnorm: -26dB
7: Subtitle (PGS), English
8: Subtitle (PGS), English
9: Subtitle (PGS), Chinese
10: Subtitle (PGS), Chinese
11: Subtitle (PGS), Portuguese
12: Subtitle (PGS), Spanish
13: Subtitle (PGS), Thai
Creating file "D:\HELLBOY\chapters.txt"...
[v02] Extracting video track number 2...
[a04] Extracting audio track number 4...
[v02] Muxing video to Matroska...
[a04] Creating file "D:\HELLBOY\feature.ac3"...
Added fps value to MKV header.
Video track 2 contains 190583 frames.
eac3to processing took 50 minutes, 17 seconds.
Done.

Rip from BD Drive E: to HDD D: using v3.05

eac3to v3.05
command line: "D:\HDDVDTL\eac3to.exe" "E:\" 1) 2: "D:\HELLBOY\New Folder\feature.mkv" 1: "D:\HELLBOY\New Folder\chapters.txt" 4: "D:\HELLBOY\New Folder\feature.ac3"
------------------------------------------------------------------------------
M2TS, 1 video track, 4 audio tracks, 7 subtitle tracks, 2:12:29
1: Chapters, 16 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: RAW/PCM, English, 5.1 channels, 16 bits, 48khz
4: AC3, English, 5.1 channels, 640kbps, 48khz
5: AC3, Thai, 5.1 channels, 640kbps, 48khz, dialnorm: -29dB
6: AC3 Surround, English, 2.0 channels, 192kbps, 48khz, dialnorm: -26dB
7: Subtitle (PGS), English
8: Subtitle (PGS), English
9: Subtitle (PGS), Chinese
10: Subtitle (PGS), Chinese
11: Subtitle (PGS), Portuguese
12: Subtitle (PGS), Spanish
13: Subtitle (PGS), Thai
Creating file "D:\HELLBOY\New Folder\chapters.txt"...
[v02] Extracting video track number 2...
[a04] Extracting audio track number 4...
[v02] Muxing video to Matroska...
[a04] Creating file "D:\HELLBOY\New Folder\feature.ac3"...
Added fps value to MKV header.
Video track 2 contains 190583 frames.
eac3to processing took 1 hour, 51 minutes.
Done.

I am still running the test on v3.04, but I can tell you right now it's results are going to be the slowest of the 3 by far.:devil:

As you can see, 2.87 beats 3.04 and 3.05 in every way. The computer was not under load during any of these tests, and you can see the command is the same for each test.

As for the controversy to add an INI file, add setting in the registry, or add an option for the command line, my vote is for the INI file. Basically Madshi could provide guide lines to give us an idea of the value to put in the INI file, and it would be up to us users to tweak the value for our system. This also eliminates the need for ac3to to write to it's directory (for those worried about that). Registry setting are more difficult to change and there's always the odd change of a less experienced user messing his/her registry up. A command line option could work, but you have to remember to set it each time, and then those of us who use GUI's will have to wait for the option to be supported. I still use yr_eac3to_more and it hasn't been updated for ages. Anyway, that's my 2 cents on that subject.

Madshi, as always, I appreciate everything you do.:thanks:

Edit: Folder rip shows 3.04/3.05 does better than 2.87, but BD drive performance with 3.04/3.05 needs some work.

[madshi]

@bigdog660, thanks for testing! You're doing:

(1) direct rip from BD drive.
(2) rip from virtual BD.

The one thing I'm really interested in is:

(3) rip from folder structure on harddisk.

I guess (3) might be more or less similar to (2), but I'm not sure. Probably (3) is the fastest of all options.

Edit: Actually (3) should be noticably different compared to (2) because eac3to v3.05 will see the virtual BD drive as a physical drive and thus use 2KB read blocks, while for (3) it will use 1MB read blocks instead.

[bigdog660]

The one thing I'm really interested in is:

(3) rip from folder structure on harddisk.

Ah, you want "eac3to 00090.m2ts 1: chapters.txt 2: movie.mkv 4: movie.ac3"?

I will add those tests to my previous post for all three versions.

[DrNein]

A problem applying large delay values to AC3 (at least) was introduced with 3.04 and remains with 3.05 (3.03 is okay). For example, if applying a value of +9472ms, eac3to might report "A remaining delay of +11712ms could not be fixed).

[madshi]

Thanks bigdog660,

so that means:

(1) v3.0x is much faster (up to 2x) than v2.87 when handling folders/files on harddisk.
(2) Using 2KB block reads slows up read access to both your physical and virtual drive compared to the 64K block reads used by v2.87.
(3) Using 1MB block reads extremely slows up read access to your physical drive, but noticably improves read access to your virtual drive, compared to v2.87.
(4) My physical drive shows much better performance with 2KB block reads than with 64K block reads.

Yippieh-yey...

[madshi]

A problem applying large delay values to AC3 (at least) was introduced with 3.04 and remains with 3.05 (3.03 is okay). For example, if applying a value of +9472ms, eac3to might report "A remaining delay of +11712ms could not be fixed).
Already found and fixed that problem earlier today. It's just a cosmetical issue. The delay was applied correctly, it's only the log output which is wrong.

[DrNein]

Already found and fixed that problem earlier today. It's just a cosmetical issue. The delay was applied correctly, it's only the log output which is wrong.

Coolsville :cool:

[mikelebron]

Any help on how I can fix this issue? The originating m2ts file works fine in players like TMT... I demuxed the m2ts file to see if this would fix the issue.. but as you can see when I try to convert it to flac it fails.. The original m2ts file was created by TSRemuxer..

eac3to v3.05
command line: eac3to audio1.thd+ac3 e:\audiott.flac
------------------------------------------------------------------------------
TrueHD/AC3, 5.1 channels, 48khz
(embedded: AC3, 5.1 channels, 640kbps, 48khz)
Extracting TrueHD stream...
Decoding with libav/ffmpeg...
Encoding FLAC with libFlac...
Creating file "e:\audiott.flac"...
[libav] Substream 1 checksum failed <WARNING>
[libav] Lossless check failed - expected 16, calculated 9d <WARNING>
[libav] Substream 1 checksum failed <WARNING>
[libav] Lossless check failed - expected 14, calculated 94 <WARNING>
[libav] Substream 1 checksum failed <WARNING>
[libav] Invalid channel 3 specified as output from matrix <WARNING>
The libav decoder reported an error while decoding. <ERROR>
Aborted at file position 53215232. <ERROR>

[madshi]

Any help on how I can fix this issue? The originating m2ts file works fine in players like TMT... I demuxed the m2ts file to see if this would fix the issue.. but as you can see when I try to convert it to flac it fails.. The original m2ts file was created by TSRemuxer..

eac3to v3.05
command line: eac3to audio1.thd+ac3 e:\audiott.flac
------------------------------------------------------------------------------
TrueHD/AC3, 5.1 channels, 48khz
(embedded: AC3, 5.1 channels, 640kbps, 48khz)
Extracting TrueHD stream...
Decoding with libav/ffmpeg...
Encoding FLAC with libFlac...
Creating file "e:\audiott.flac"...
[libav] Substream 1 checksum failed <WARNING>
[libav] Lossless check failed - expected 16, calculated 9d <WARNING>
[libav] Substream 1 checksum failed <WARNING>
[libav] Lossless check failed - expected 14, calculated 94 <WARNING>
[libav] Substream 1 checksum failed <WARNING>
[libav] Invalid channel 3 specified as output from matrix <WARNING>
The libav decoder reported an error while decoding. <ERROR>
Aborted at file position 53215232. <ERROR>
I'd guess that either tsMuxeR or TsRemux did some nasty things to the TrueHD track. I'd suggest reripping the original disc and decoding that with eac3to.

[madshi]

Hello Madshi! Finally, here are my test results for all three versions.
Could you please keep that Hellboy source, so that you can retest later with v3.06? That would be nice - thanks!

[bigdog660]

Could you please keep that Hellboy source, so that you can retest later with v3.06? That would be nice - thanks!

No problem... thanks!

[tebasuna51]

The clipping MP2 is uploading. I re-verified that both MPG -> MP2 -> AC3 and MPG -> AC3 both produce clipping, but MPG -> MP2 -> 32float WAV (with Foobar) > AC3 (with eac3to) works fine.

Here is a sample (12 sec) with the problem isolated (http://www.sendspace.com/file/5nm3yr), is decoded fine with Foobar2000, BeSweet, NicAudio and also ffmpeg, but using eac3to-libav there are a inversion at clipping points than cause audible cliks (see the png included)

I hope than help to fix the problem.

[honai]

I have both the US and German Blu-rays of WALL-E.

Surprisingly, eac3to shows a runtime of 1:38:25 (00095.mpls) for the US disc, but 1:32:43 (00119.mpls) for the German disc.

I have noticed that the US version consists basically of a single large M2TS, but the German version is split up into lots of smaller segments. eac3to also reports many overlaps for the German disc.

Since I don't believe that they cut 6 minutes of footage for the German market, is it possible that eac3to realizes the gaps incorrectly? (The resulting audio files for the German disc are in fact 1:33:35 long.)

[madshi]

I hope than help to fix the problem.
It will help, thanks!

I have both the US and German Blu-rays of WALL-E.

Surprisingly, eac3to shows a runtime of 1:38:25 (00095.mpls) for the US disc, but 1:32:43 (00119.mpls) for the German disc.
Strange. My "Englisch.flac" from the US disc is 1:38:11 long, so 1:32:43 is definitely too short. Does the eac3to title listing (which you get if you simply do "eac3to blurayDrive:") also list 1:32:43? If so, the overlap removal can not be responsible for the too short runtime, because the overlap removal is only post processing. Are there no other playlists with a bigger runtime on the German disc? Have you tried actually processing the disc? Maybe the runtime display is simply wrong and processing the disc will still work nevertheless?

Maybe you could upload the CLIPINF and PLAYLIST folders? Zipped it should be only a few KBs. Thanks!

P.S: What does playlist "00082.mpls" from the German Blu-Ray say? You can do "eac3to bluRayFolder\PLAYLIST\00082.mpls", if this playlist isn't offered by default.

[honai]

Thanks. Yes, I already checked out that possibility. For 00082.mpls it says 1:32:31 for the German disc. I have seen somewhere else that for this playlist the runtime is supposed to be 1:38:32, that's why I wondered if maybe eac3to is making a mistake.

I have also observed that for 00119.mpls (German) eac3to initially reported 1:32:43 runtime in the tracklisting, when selecting the title for demuxing it shows 1:33:33, but demuxed/processed runtime was 1:33:35, so it seems that those are guesses by eac3to anyway, right? I'm especially wondering about the discrepancy between the initial title listing and the listing when that title is selected.

And yes, 00119.mpls and 00120.mpls are the longest-running titles displayed.

Here's the requested archive:

http://www.sendspace.com/file/ufd3xb

Thanks for looking into this, much appreciated.

EDIT:

After verifying each file from the 00082.mpls I found that one of my M2TS was corrupt. Doh! Will try again, but I guess this fixes it. Sorry for wasting your time.

EDIT:

Could you please add a sanity check if one of the M2TS files referenced in the playlist has a size of 0 bytes or is missing altogether from HDD? I have noticed that in cases like above eac3to will silently ignore the missing/corrupt file. Thanks!

[Snowknight26]

eac3to doesn't seem to encode 32-bit FLACs, but works fine if I remove -down32, resulting in a 24-bit FLAC:

eac3to v3.05
command line: eac3to.exe "Z:\Encoding Tools\temp\audio\2fast2furious.eac3" "Z:\Encoding Tools\temp\audio\2fast2furious.flac" -down32
------------------------------------------------------------------------------
E-AC3, 5.1 channels, 1:47:36, 1536kbps, 48khz
The Nero decoder doesn't seem to work, will use libav instead.
Decoding with libav/ffmpeg...
Remapping channels...
Reducing depth from 64 to 32 bits...
The FLAC encoder received a non-supported data format.
Aborted at file position 262144.

Also, any reason why creating a silent AC3 (E-AC3?) frame would fail?
eac3to v3.05
command line: eac3to.exe "G:\hotfuzz" 1) 4: ..\temp\audio\hotfuzz.eac3
------------------------------------------------------------------------------
EVO, 1 video track, 6 audio tracks, 7 subtitle tracks, 2:00:52
4: E-AC3 EX, English, 5.1 channels, 1536kbps, 48khz, dialnorm: -27dB, 133ms
[a04] Extracting audio track number 4...
[a04] Removing E-AC3 dialog normalization...
[a04] Applying (E-)AC3 delay...
[a04] Creating silent AC3 frame failed. <WARNING>
[a04] Creating file "..\temp\audio\hotfuzz.eac3"...
Video track 3 contains 173880 frames.
eac3to processing took 3 minutes, 8 seconds.
Done.

[madshi]

Could you please add a sanity check if one of the M2TS files referenced in the playlist has a size of 0 bytes or is missing altogether from HDD? I have noticed that in cases like above eac3to will silently ignore the missing/corrupt file. Thanks!
Will add a warning...

eac3to doesn't seem to encode 32-bit FLACs, but works fine if I remove -down32, resulting in a 24-bit FLAC
FLAC does not support 32bit, highest bitdepth supported is 24bit. BTW, some experts believe that even 16bit is good enough, others disagree. But all experts agree that 24bit is more than enough. So there's no reason to go 32bit, anyway, unless you want to do further processing on the file...

Also, any reason why creating a silent AC3 (E-AC3?) frame would fail?
Silent frame creation only works for AC3 because Aften doesn't support E-AC3 encoding yet. It's a bug that eac3to even tries to encode a silent E-AC3 frame, but it's only a cosmetical problem.

[Snowknight26]

FLAC does not support 32bit, highest bitdepth supported is 24bit.

http://flac.sourceforge.net/faq.html#general__samples
FLAC supports linear PCM samples with a resolution between 4 and 32 bits per sample.

:\

So there's no reason to go 32bit, anyway, unless you want to do further processing on the file...

...or for Fun. I was just trying to see how big a 64-bit floating point FLAC file (from an EAC3 file) would be, but since it doesn't support floating point precision, I wen't for 32, then 24bit when that didn't work.

[Inspector.Gadget]

Hey Madshi, quick question:

I'm using eac3to through the HD-DVD/Blu-ray Streams Extractor to pull some audio off a concert Blu-ray. Currently, I'm muxing the audio (extracted as AC3, FLAC, and DTS) to MKV with MKVMerge, splitting the resulting .MKA file by chapter, and then demuxing the audio from each resulting .MKA segment. I'm doing this in order to split the audio tracks by song. Is there a faster way to do this, perhaps during extraction or transcoding? Thanks.

[madshi]

http://flac.sourceforge.net/faq.html#general__samples
Maybe the spec supports it, but I think the official encoder does not. See here:

http://www.hydrogenaudio.org/forums/lofiversion/index.php/t23613.html

It's possible that this post is outdated, though, not sure...

Is there a faster way to do this, perhaps during extraction or transcoding?
Right now it's not possible with eac3to, if that's what you're asking. Don't know what you can or can not do with other tools.

[Snowknight26]

Maybe the spec supports it, but I think the official encoder does not. See here:

http://www.hydrogenaudio.org/forums/lofiversion/index.php/t23613.html

It's possible that this post is outdated, though, not sure...

Oh well, not like it was an issue to begin with. :p

[Blue_MiSfit]

Hi Madshi,

Did you get a chance to peek at my problematic MP2? It's the one with clipping etc..

Thanks,
~MiSfit

[madshi]

Did you get a chance to peek at my problematic MP2? It's the one with clipping etc..
Yes. It decodes without clipping when using "-nero" or "-sonic", so the issue is related to libav decoding. I'm checked and libav returns the data to me with clipping in the data and I don't really see how I can detect and remove that. I think I'll have to update to the latest libav SVN version and maybe do some patches to get floating point from libav instead of integer samples. Then I might get it solved. However, this is not likely to happen this week. Maybe next. For now you can use Nero or Sonic for decoding...

[Snowknight26]

Madshi, if you are thinking about doing that (the patch for floating point support), you might wish to submit your changes to the SVN as well, for everyone's benefit.

[GZZ]

I think I found a small cosmetic error when parsing a playlist file:

Result:


d:\eac3to>eac3to "H:\BDMV\PLAYLIST\00000.mpls"
1) 00000.mpls, 0:50:10
[4+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+
5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+
5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5].m2ts
- h264/AVC, 1080p24 /1.001 (16:9)
- RAW/PCM, English, multi-channel, 48khz


Not sure it should say 5+5+5+5+5+5...... it should just be [4+5].m2ts

I have attached the playlist file here, for you to test it.

http://hbar.dk/files/00000.rar

[madshi]

I think I found a small cosmetic error when parsing a playlist file:

Not sure it should say 5+5+5+5+5+5...... it should just be [4+5].m2ts
Some playlists are really that stupid. I don't think it's a bug.

[madshi]

eac3to v3.06 released

http://madshi.net/eac3to.zip

* added MKV reading/parsing support
* added demux support for MKV (E-)AC3, DTS(-HD), AAC, MPx, FLAC and WAV tracks
* added demux support for MKV "modern style" MPEG2, VC-1 and h264/AVC tracks
* reading from (HD) DVD and Blu-Ray drives uses different reading APIs now
* empty tracks in TS/m2ts container are not listed, anymore
* for 24.000 fps video tracks a little warning is displayed now
* when demuxing subtitle files, the number of captions is added to the filename
* timestamp derived FPS is used for gap checking instead of video bitstream FPS
* fixed: 44.1khz AC3 encoding was still broken
* fixed: zero byte stripping pass was done for true 24bit TrueHD tracks
* fixed: downconverting WAV files with 0x3f channel mask didn't work
* fixed: log output "remaining delay [...]" was sometimes wrong for AC3 tracks
* fixed: silent frame creation was tried for E-AC3 although it can't work
Please note that MKV read support is not complete yet. E.g. subtitles and chapters can't be demuxed yet. Also some MKV files muxed with old versions of mkvtoolnix, gdsmux or other muxing tools may not work correctly. If you run into any trouble with audio/video tracks, just let me know.

Good news is that MKV video muxing and demuxing is now a transparent operation, if you use eac3to both for muxing + demuxing. In other words: If you mux a video track with eac3to and then demux it again, you'll get the exact same data back. No changes, nothing missing... *)

-------

*) exceptions:

(1) of course eac3to does some video bitstream manipulations like cropping 1088 to 1080, removing padding bytes etc, but these changes are done intentionally and are not caused by muxing/demuxing
(2) VC-1 muxing loses the very last video frame, don't know why

[d1g1ta7]

On the NBC HDTV muxes used to distribute programming to network affiliates in the US, NBC sends the surround audio via 3 stereo tracks - the first contains front left and front right audio, the second contains the center and lfe, the third contains rear left and rear right. Would it be possible to combine these tracks in eac3to, outputting as 5.1?

[Snowknight26]

C:\unzipped\eac3to>eac3to.exe "Z:\Movies\1408\1408.mkv"
MKV, 1 video track, 1 audio track, 16 subtitle tracks, 1:52:26, 24p /1.001
1: V_MPEG4/ISO/AVC, English, 1920x800p (12:5)
2: DTS, English, 5.1 channels, 16 bits, 1509kbps, 48khz
3: S_TEXT/ASS, Finnish, "Finnish"
4: S_TEXT/ASS, Finnish, "Finnish"
5: S_TEXT/ASS, Finnish, "Finnish"
6: S_TEXT/ASS, Finnish, "Finnish"
7: S_TEXT/ASS, Finnish, "Finnish"
8: S_TEXT/ASS, Finnish, "Finnish"
9: S_TEXT/ASS, Finnish, "Finnish"
10: S_TEXT/ASS, Finnish, "Finnish"
11: S_TEXT/ASS, Finnish, "Finnish"
12: S_TEXT/ASS, Finnish, "Finnish"
13: S_TEXT/ASS, Finnish, "Finnish"
14: S_TEXT/ASS, Finnish, "Finnish"
15: S_TEXT/ASS, Finnish, "Finnish"
16: S_TEXT/ASS, Finnish, "Finnish"
17: S_TEXT/ASS, Finnish, "Finnish"
18: S_TEXT/ASS, Finnish, "Finnish"
Only the last track is Finnish.

And then funny enough, the next mkv I had muxed says
C:\unzipped\eac3to>eac3to.exe "Z:\Movies\11-14\11-14.mkv"
MKV, 1 video track, 1 audio track, 1:25:43, 23.975p
1: V_MPEG4/ISO/AVC, English, 1080p (16:9)
2: DTS, English, 5.1 channels, 24 bits, 1509kbps, 48khz

And finally..
C:\unzipped\eac3to>eac3to.exe "Z:\Movies\The Third Man\the third man.mkv"
MKV, 1 video track, 4 audio tracks, 1:45:13, 24p /1.001
1: V_MPEG4/ISO/AVC, English, 1436x1080p (359:270)
2: FLAC, English, 1.0 channels, 1:45:13, 16 bits, 48khz
"FLAC 1.0 @ 202kbps"
3: A_VORBIS, English, 1.0 channels, 48khz
"Abridged recording of Graham GreeneÆs treatment, read by actor Richard Clarke"
4: A_VORBIS, English, 1.0 channels, 48khz
"Abridged recording of Graham GreeneÆs treatment, read by actor Richard Clarke"
5: A_VORBIS, English, 1.0 channels, 48khz
"Abridged recording of Graham GreeneÆs treatment, read by actor Richard Clarke"
Only the last track has that description. And that Æ is really a ´. Guess eac3to doesn't support unicode?

Samples can be provided if needed.