eac3to - audio conversion tool

[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]

Originally Posted by 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?

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]

Originally Posted by 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.

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]

Originally Posted by aneurysm

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]

Originally Posted by 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.

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]

Originally Posted by SquallMX

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...

[rapscallion]

Originally Posted by 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.

Probably because they're not the same decoders. Eac3to uses a "patched" version that only madshi can supply.

[Jan Marijniszoon]

Originally Posted by kypec

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

Do you perhaps have any insight how to disable it in ffmpeg? I tried the option "-drc_scale 0" but that didn't do much.

Originally Posted by rapscallion

Probably because they're not the same decoders. Eac3to uses a "patched" version that only madshi can supply.

And let me guess, madshi's version is much better tuned right?

[Jan Marijniszoon]

I fixed it; I had put the option in the wrong order in the command line.

Using this:

ffmpeg -drc_scale 0.000000 -i sound.ac3 -f wav sound.wav

gave me the exact same wav-file as was produced by eac3to.

Thank you for getting me in the right direction.

[kws53]

Originally Posted by 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.

Same problem here - did anyone notice the 108.607p in the opening line? My log for the 2D version is similar but produces another bizarre number - 95.907p.

M2TS, 1 video track, 7 audio tracks, 8 subtitle tracks, 1:33:37, 95.907p
1: Chapters, 37 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: TrueHD/AC3, English, 7.1 channels, 48kHz (embedded: AC3, 5.1 channels, 640kbps, 48kHz)
4: AC3 Surround, English, 2.0 channels, 320kbps, 48kHz
5: AC3 Surround, English, 2.0 channels, 320kbps, 48kHz
6: AC3, French, 5.1 channels, 512kbps, 48kHz
7: AC3, French, 5.1 channels, 640kbps, 48kHz
8: AC3, Spanish, 5.1 channels, 640kbps, 48kHz
9: AC3, English, 2.0 channels, 320kbps, 48kHz
10: Subtitle (PGS), English
11: Subtitle (PGS), English
12: Subtitle (PGS), French
13: Subtitle (PGS), Spanish
14: Subtitle (PGS), English
15: Subtitle (PGS), French
16: Subtitle (PGS), Spanish
17: Subtitle (PGS), English

Cheers,
Kurt

[damorsoft]

I have been trying for days to make the code below work.
If I set createnowindow=true and
disable standard output eac3to runs fine in the command box but just locks up when run with the command box hidden.

This same routine works for mkvmerge tsmuxer and eac3to to read the mpls files.\
I have tried read, readline and readtoend all without success.

Any thoughts thanks


Public Function StartFile(ByVal MyApp As String, ByVal MyTail As String) As Integer
Dim myProcess As New Process()
'Dim test As String = Chr(8)
myProcess.StartInfo.WorkingDirectory = Application.StartupPath
myProcess.StartInfo.FileName = MyApp
myProcess.StartInfo.Arguments = MyTail
myProcess.StartInfo.UseShellExecute = False
'myProcess.StartInfo.CreateNoWindow = false
myProcess.StartInfo.CreateNoWindow = True
myProcess.StartInfo.RedirectStandardOutput = True
'myProcess.StartInfo.RedirectStandardError = True
Try
myProcess.Start()
myProcess.PriorityClass = ProcessPriorityClass.Idle
While (myProcess.HasExited = False)
Application.DoEvents()
Dim sLine As String = myProcess.StandardOutput.ReadToEnd
If (Not String.IsNullOrEmpty(sLine)) Then
TextBox14.Text = sLine
End If

If UserCancel Then
myProcess.Kill()
ProcEC = 9
Return ProcEC
End If
End While
ProcEC = myProcess.ExitCode
Catch ex As Exception
MsgBox(" Error(s) with startfile " & MyApp & " " & ex.Message)
ProcEC = 99
End Try
myProcess.Close()
Return ProcEC
End Function

[Soul Taker]

Hi there. I'm a bit confused about something, here it is...

1: Chapters, 9 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: RAW/PCM, Japanese, 2.0 channels, 24 bits, 48kHz
4: DTS Master Audio, Japanese, 5.1 channels, 24 bits, 48kHz
   (core: DTS, 5.1 channels, 24 bits, 1509kbps, 48kHz)
5: TrueHD/AC3, Japanese, 5.1 channels, 48kHz
   (embedded: AC3, 5.1 channels, 448kbps, 48kHz)
6: AC3, Japanese, 2.0 channels, 384kbps, 48kHz
7: Subtitle (PGS), Japanese
a04 Extracting audio track number 4...
a04 Decoding with ArcSoft DTS Decoder...
a04 Encoding FLAC with libFlac...
a04 Creating file "C:\Users\ST\Desktop\1_4_audio.flac"...
a04 The original audio track has a constant bit depth of 16 bits.
a04 Superfluous zero bytes detected, will be stripped in 2nd pass.
a04 Starting 2nd pass...
a04 Decoding FLAC...
a04 Reducing depth from 24 to 16 bits...
a04 Encoding FLAC with libFlac...
a04 Creating file "C:\Users\ST\Desktop\1_4_audio.flac"...
a04 The processed audio track has a constant bit depth of 16 bits.
Video track 2 contains 133434 frames.
eac3to processing took 10 minutes, 12 seconds.
Done.

-Is reducing the audio depth from 24 to 16 bits... normal? and i have to say, this the first time that happened to me.

[rapscallion]

At first glance, far too many Japanese audio/sub tracks.

Seriously though, completely normal when there is padding present. Happens all the time. By eac3to removing it doesn't change the quality at all. Still lossless.

BTW, no one can accuse you of being a post whore, 1 post in 4 years!!

[Soul Taker]

^^^

That's Berserk movie for ya... too much tracks and you only need 2 (facepalm).
LMFAO!! I'm not a forum guy... and i don't know why can't i find it interesting to "camp" 24/7
BTW, i don't even post that much in our own forum "non-american,EU guy"
Anyway, thanks for your reply dude

سلام <~

[bilditup1]

Hey all,
I tried about five times now to encode the DTS-MA audio from 'Fellowship of the Ring' using Arcsoft, eac3to, and Nero. Every single time, instead of a 1h:45min multichannel file, I get a 2:00:48 file that's all distorted and useless. I have no idea why this is happening. It's a 6.1 DTS, which there was some info about earlier in the thread about remappings and such from about a year ago. The information does not seem applicable though, since it's about a year old, and since I don't receive any error messages about channel mappings (eac3to automatically detects that it's a 6.1 file and doubles the back channel in order to facilitate compatibility with NeroAacEnc). In any case, I tried what was suggested - manual channel mapping plus the '-double7' switch - and it changed nothing. I also tried to encode just the DTS-ES core - that didn't help at all. Thanks to the Arcsoft filters, the DTS file does play in MPCHC, but a) with terrible seeking b) a reported running time of 05:24:44. I am using Arcsoft 1.1.0.8, eac3to 3.24, and Nero 1.5.4.0.
Anybody know how to encode this thing?
-e

[bilditup1]

Hmm, after tracking down several different versions, this seems to be an issue with any version of Arcsoft above 1.1.0.1 with 6.1 tracks. Getting the old DLL is the key.