eac3to - audio conversion tool

[mr.duck]

Definitely use FLAC. There's nothing else that's better while being open source and widely supported. For stereo music, file size is around 60% using FLAC compared to WAV.

[ajamils]

I'm trying to rip a Blu-ray using HdBrStreamExtractor (which is a GUI for eac3to) and I'm getting the following error. I also tried ripping the same blu-ray with anotherEac3to GUI and Blu-rip and all failed with the same error. It seems like eac3to does not like extracting the audio which is in Mayan language. Any suggestion ?

15:52:07] a03 Creating file "M:\Hidef Movies\1080p\Apocalypto\1_3_audio.flac"...
[15:52:18] The "-seekToIFrames" option may work around that.
[15:52:23] v02 Waiting for DirectShow decoder thread to finish. Please wait...
[15:52:28] Error: Unfortunately the Haali Muxer cannot handle this source file.It doesn't contain enough seek/recovery points.Aborted at file posi
[15:52:28] Stream Extraction Completed

[TinTime]

It's nothing to do with the audio. eac3to (or specifically the haali muxer) doesn't handle some AVC streams when muxing to mkv. The Apocalypto blu-ray is one of these types.

Demux to raw AVC and then mux with mkvmerge.

[Shamus76]

I'm trying to rip a Blu-ray using HdBrStreamExtractor (which is a GUI for eac3to) and I'm getting the following error. I also tried ripping the same blu-ray with anotherEac3to GUI and Blu-rip and all failed with the same error. It seems like eac3to does not like extracting the audio which is in Mayan language. Any suggestion ?

Earlier post by madshi explains the error:

"There's a bug in the Haali Matroska Muxer which results in a total freeze when muxing some h264 movies. eac3to detects this situation and aborts processing directly before the Haali Matroska Muxer freezes. Currently there's no way to properly mux such a movie with eac3to respectively with Haali's Matroska Muxer. You can use the option "-seekToIFrames" to mux the movie in a different way. This should succeed. However, this comes at a cost: Sometimes when seeking such a movie there are very noticable image artifacts for a short time (max a few seconds). Haali knows about this problem but hasn't fixed it yet, sadly."

I used the "-seekToIFrames" option and it works fine and i haven't yet had any problems with artifacts.

[ramicio]

I have a mono (1.0) DTS-HD Master audio file I'm trying to decode and it won't work. The output is:
"The ArcSoft DTS Decoder reported an error while decoding. Aborted file at position 262144."

Tried it directly from the m2ts file and it gave the same error, just a different position number. Eac3to shows the correct info about the file, but the decoder doesn't like it. Anything else to try here? I want lossless, I don't wan't just the core!

[deathlord]

I have a mono (1.0) DTS-HD Master audio file I'm trying to decode and it won't work. The output is:
"The ArcSoft DTS Decoder reported an error while decoding. Aborted file at position 262144."

Tried it directly from the m2ts file and it gave the same error, just a different position number. Eac3to shows the correct info about the file, but the decoder doesn't like it. Anything else to try here? I want lossless, I don't wan't just the core!

Try -sonic !

[ramicio]

Hehe I am ripping my hair out trying to find the sonic decoder. I don't even know what to look for. I am trying to get Cineplayer HD-DVD Player 4.2 with no luck so far. And I'm sure once I do, it probably won't work.

Well I found it, and I am ripping my hair out once again trying to figure out why it won't work. It's giving a "can't find mfc71.dll" error when I run "eac3to -test" and it gets to the part where it checks the sonic decoder.

The mfc71.dll error is gone, and I found 4.3.0.169. This version is showing as installed but not working in eac3to as well. Would this have anything to do with having an x64 version of windows? I can use the sonic filter in graphedit but it makes a 16-bit file, not 24 :( The sonic decoder is only decoding the core of the dts file. HELP!!!

[LeXXuz]

I must be blind. Again. Please tell me how do I create six WAV files decoded from a 6ch dts source?

I always end up with one (probably 6-ch) wav file when I use "eac3to input.dts output.wav". I only get 6 intermediate wave files when I set .dts as output format to feed the dts encoder directly afterwards.
But I dont want that, because my DTS encoder is on another machine where I'd like to import those WAV's.

[nurbs]

eac3to input.dts output.wavs

[LeXXuz]

eac3to input.dts output.wavs

Ah no way! It can't be that obvious. :D
:thanks:

[[)370|\|470!2]

eac3to v3.22
command line: "D:\TRANS\eac3to3.22\eac3to.exe" "E:\Batman.The.Dark.Knight\odds\Batman.track_4354.ac3" "D:\Batman\Batman.track_4354.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 "D:\Batman\Batman.322.track_4354.flac"...
[libav] Substream 0 parity check failed <WARNING>
[libav] Substream 0 checksum failed <WARNING>
[libav] Lossless check failed - expected 87, calculated 92 <WARNING>
[libav] Substream 1 parity check failed <WARNING>
[libav] Substream 1 checksum failed <WARNING>
[libav] Lossless check failed - expected 85, calculated 33 <WARNING>
[libav] Substream 0 parity check failed <WARNING>
[libav] Substream 0 checksum failed <WARNING>
[libav] Lossless check failed - expected fd, calculated c9 <WARNING>
[libav] End of stream indicated <WARNING>
The original audio track has a constant bit depth of 16 bits.
Superfluous zero bytes detected, will be stripped in 2nd pass.
Starting 2nd pass...
Decoding FLAC...
Reducing depth from 24 to 16 bits...
Encoding FLAC with libFlac...
Creating file "D:\Batman\Batman.track_4354.flac"...
The processed audio track has a constant bit depth of 16 bits.
eac3to processing took 24 minutes, 28 seconds.
Done.

Any ideas what could be wrong with the track? Oh, and inb4, I own the original disc.

[BatKnight]

Any ideas what could be wrong with the track? Oh, and inb4, I own the original disc.
Looks like a corrupted or broken track. You could try to re-rip the track, since you own the original disc. Or, better than that, you could rip the TrueHD track directly to FLAC, using eac3to.

[[)370|\|470!2]

You could try to re-rip the track, since you own the original disc.
But of course, it was the first thing I've tried to no avail.
Or, better than that, you could rip the TrueHD track directly to FLAC, using eac3to.
Already done. The question is how am I to be sure if it's b0rked or not.

[setarip_old]

@[)370|\|470!2

Already done. The question is how am I to be sure if it's b0rked or not.Post the log (Just as you did for the ripped-to-harddrive version)...

[[)370|\|470!2]

@[)370|\|470!2

Post the log (Just as you did for the ripped-to-harddrive version)...

The log posted above actually is.

[nurbs]

What happens if you convert to flac without demuxing the track first?

Also, since the source file in the command line is a .ac3 I find it strange that it says the content is TrueHD. I thought the had a .thd extnsion.

[[)370|\|470!2]

What happens if you convert to flac without demuxing the track first?
That's brilliant. Just tell me what command line to use to achieve that.
since the source file in the command line is a .ac3 I find it strange that it says the content is TrueHD. I thought the had a .thd extnsion.
And I thought file's being recognized by its headers, not the extension.

[setarip_old]

@[)370|\|470!2
"E:\Batman.The.Dark.Knight\odds\Batman.track_4354.ac3" "D:\Batman\Batman.track_4354.flac"
This line from the log certainly doesn't indicate that the source is your original disc (as I suggested you use)...

[nurbs]

That's brilliant. Just tell me what command line to use to achieve that.
eac3to DiscFolder shows the playlists
eac3to DiscFolder 1) shows the tracks in the playlists
eac3to DiscFolder 1) 3:audio.flac encodes the third track in the first playlist to flac

And I thought file's being recognized by its headers, not the extension.
Well that depends, doesn't it? I suspect eac3to does, but if you double click on a file with a .doc extension I wouldn't expect a media player to pop up even if the file is actually an .mp3, at least not on windows.

Anyway what software did you use to extract the audio? Did that software put the wrong extension on the file or did you do that?

[[)370|\|470!2]

if you double click on a file with a .doc extension I wouldn't expect a media player to pop up even if the file is actually an .mp3, at least not on windows.
Obviously you should learn a bit about the file assotiation per se and how it works.

Anyway what software did you use to extract the audio? Did that software put the wrong extension on the file or did you do that?
Let me get this straight — you're claiming that extension is a problem there?

[nurbs]

Let me get this straight — you're claiming that extension is a problem there?
No, I'm thinking something went wrong during demuxing the .m2ts files, which is why I asked what software you used to demux the audio. If it was eac3to you'd end up with a .thd extension, so you either renamed it or you used something else. I'd be interested in how you ended up with the file so I'll know how to avoid such problems.

So, have you found time to try if reencoding the audio straight from the .m2ts without demuxing it first works?

[xkodi]

Will be anything made with the decoding of "strange setup" 7.1?

solution for that problem was finally found:

http://forum.doom9.org/showthread.php?t=156168

actually, that approach could be used for every DTS-HD (MA) file that Arcsoft can't decode correctly and respectively eac3to can't.

i wish eac3to be able to write such 140 bytes headers for easier decoding of DTS-HD (MA) file outside eac3to in case that is necessary.

[sub24ox7]

yes PLEASE!!! that would be so awesome I can't decode a DTS-HD mono track at this very moment :(

[madshi]

Maybe this is a bug in eac3to:

I always rip my BRs directly with eac3to like this:
eac3to d: 1) -demux

This was functioning for 100% of my BRs the last years. With the new version 3.22 i get the following error on ~50% of my discs
That's weird. I have a hard time believing that the new eac3to is responsible for the problems. Maybe something else changed on your PC? It seems nobody else has this problem.

I just tried extract DTS-ES Discrete 6.1 to wav(input.dts output.wavs) with Arcsoft Decoder (version 3.0.160) and it produced 7 individual WAV files, but there was something wrong with them. Too much high-frequency and noise.
Arcsoft decoder cannot properly decode 6.1 dts. I had the same problem.
Newer versions (e.g. 1.1.0.7) of the dtsdecoder.dll seem to have this problem. Older versions (e.g. 1.1.0.0) work just fine.

Could you allow for longer -edits, in particular silence? At the moment the maximum possible (positive) edit seems to be 4999ms.
Yes, will change that.

WARNING:
- When the language field of a track (in mkv) is empty this mean the language is the default: eng (from MkvMerge v4.0.0)
- eac3to don't manage audio tracks (MP2/MP3/DTS/AC3?) from mkv's generated with MkvMerge v4.1.0 defaults (header compression).
- eac3to crash (without messages) with video track H264 from mkv's generated with MkvMerge v4.2.0 defaults (header compression).

@madshi

Do you have any plan to support these new defaults?
Yes.

Hi, is there a way to stretching an audio file to a given time?
In my case I would like to stretch a track by adding 400ms to it, is it possible with eac3to?
It is not possible with eac3to because the resampling library is limited to specific stretching factors.

An audio file (dts, ac3, ...) don't have tags about the video fps, only have a duration. And aply a -24.000 -changeTo23.974 means only modify the duration with a coefficient of 1.001

With audio files -slowdown means modify the duration with a coefficient of (1001/960) always.
FWIW, "-slowdown" always defines a target FPS value of 23.976. You can do "-24.000 -slowdown" and it will do a 24.000 -> 23.976 slowdown.

I have a Blu Ray disc of a tv show (Supernatural Season 1, Disc 1). The disc has the first 6 episodes of the tv show. When I run the disc through eac3to (using Clown_BD and/or Ripbot) eac3to only picks up 3 playlists (the 1st playlist is of all episodes, the 2nd playlist is of episode 1, and the 3rd playlist is of episode 2). Episode 3-6 don't show anywhere. If I use MakeMKV I can see all episodes listed out individually to select. Is there anything you can think of that would be causing this issue?
I've seen this before and just thought that there were not any playlists for the other episodes. But maybe there are and there's a bug in eac3to. Can you please zip up the playlist and clipinf folders for me?

The decoding by libav under XP failed too.

What this can be?
Broken TrueHD track.

eac3to cannot fully demux my TS files (from DVB-T, UK).

Unlike other programs like tsMuxeR, eac3to at least recognizes that there are subtitles there. But -demux only extracts the video and audio.
I don't know how to demux DVB subtitles in any format that can be used by other applications.

Also when I -demux some <path>\video.ts, it extracts the audio and video to the same folder as eac3to.exe, not the video file folder and no other way of setting the output to another folder. Pretty annoying.
Just use "eac3to source c:\whatever\movie.*" that will demux all tracks to any desired target path.

How do I see which episode is which?
Often there's a "play all" playlist. It usually lists the episodes in the right order.

Sometimes, when I join multiple m2ts files and demux the streams, the end result shows 13 hours as duration.
Simply joining multiple m2ts files makes problems because after joining it is not possible for eac3to (or any other program) to quickly see that the file was joined from multiple smaller files and that the timestamps do not match and where each smaller file starts and ends in the joined file. This is the way it is. If you manually join m2ts files, you'll have to live with this effect.

Can eac3to demux DTS Express audio tracks?
Yes.

I come back to this problem with more explanations and tests. In fact, the problem is not new, I just verified and I have the same strange behaviour with eac3to v3.21 and eac3to v3.18.

Here is my scenario:
1 - eac3to to demux video in MKV container and convert audio to AC3
2 - TsMuxer to mux audio and video in a M2TS container
3 - playback of the M2TS file with the PS3

Video is H.264. When the file is decoded by the PS3, I have many macroblocks, and the result is the same whatever the version of eac3to (3.18, 3.21 and 3.22).
If at step 1, instead of demuxing video in MKV container, I demux the video in a H.264 file, then the playback with the PS3 is fine without macroblocks.

Note that all these files (M2TS and MKV) are played correctly on the PC.

So the problem is relative to the usage of MKV container, either when produced by eac3to, or when used as input by TsMuxer. And the problem is noticeable only when the final file is played with the PS3.
If you do this:

(1) demux blu-ray directly, by using eac3to
(2) mux video to MKV by using eac3to, then demux again by using eac3to

The demuxed raw h264 video file produced by both methods is identical. So the problem must obviously be caused by tsMuxeR not handling MKV input correctly.

[madshi]

eac3to don't remove the dialog normalization with Arcsoft decoder (1.1.0.1)

Test .dtshd

http://multi-up.com/295013

DNorm.rar - center before and after decoding.
I've checked this and all decoders output the same volume - even libav which definitely doesn't do dialnorm processing for DTS when eac3to removes it from the headers. I believe that the volume was already changed (hard coded) by the DTS encoder. And I believe that ArcSoft totally ignores the dialnorm when decoding.

One key information is that decoding the track with ArcSoft and Sonic decoders output bit perfect identically results. Which means that decoding should be lossless which would not be the case if dialnorm processing was active.

[madshi]

I just noticed that a bug which I had reported months ago is still present.
The mapping of 3.0 soundtracks converted to flac is incorrect. The center channel ends up in the left surround.
This time the source was DTS MA 3.0 (last time: PCM 3.0), as found on the Criterion BluRays of Yojimbo and Sanjuro, so I don't think it's a decoder problem.
When creating Mono-Wavs instead of flac, the three tracks are correctly titled L, R and C.
The FLAC is correct. The latest madFlac v1.9 now also outputs the correct channelmask (0x7). The previous version used channelmask 0xffffffff. If you still get incorrect channel assignments then it's the fault of some other filter, maybe even the audio renderer. eac3to and madFlac definitely handle 3.0 correctly now.

[madshi]

Could you allow for longer -edits, in particular silence? At the moment the maximum possible (positive) edit seems to be 4999ms.
I've checked. There's no specific limitation for the "-edit" command. You cannot edit in such a way, though, that looping wouldn't work. E.g. "-edit=0:00:01,+2000ms" is not allowed, but "-edit=0:00:05,+2000ms" works just fine.

[madshi]

Was able to find a small enough sample to be able to reproduce the issue:

http://stfcc.org/misc/eac3to.aac.issue.zip

Run the bat, wait for eac3to to stop outputting. Might be a while, but it will. Either put the two files in the folder eac3to is in or modify the bat.
I think I got a fix for this one. Could you please try with the next eac3to build and report back?

[madshi]

I'm seeing odd behavior with Battleship Potemkin, a newly restored BluRay release from Kino.
Thanks for the upload, the problem will be fixed in the next build.

[madshi]

@madshi
can you add option to automatically ignore .m2ts in playlist if number of audio channels is not constant. In this example also frame rate is different in first file.

Movie Downfall
eac3to v3.22
------------------------------------------------------------------------------
1) 00014.mpls, 00034.m2ts+00014.m2ts, 2:35:21
- Chapters, 35 chapters
- VC-1, 1080p24 /1.001 (16:9)
- AC3, German, stereo, 48kHz

00034.m2ts
M2TS, 1 video track, 1 audio track, 0:00:37, 29.766p
1: Chapters, 35 chapters
2: VC-1, 1080p24 /1.001 (16:9)
3: AC3, German, 2.0 channels, 192kbps, 48kHz, dialnorm: -27dB

00014.m2ts
M2TS, 1 video track, 1 audio track, 0:00:29, 24p /1.001
1: VC-1, 1080p24 /1.001 (16:9)
2: AC3, German, 5.1 channels, 640kbps, 48kHz, dialnorm: -27dB

Hmmmmm... This is a difficult one. Sometimes there might be a small intro with different channels before the real movie which I could easily ignore without doing any damage. But then there might be movies where actually different parts have different audio tracks (e.g. seamless branching theatrical cut vs. director's cut). How can eac3to know? E.g. if the first m2ts file is 10 minutes long, shall I still cut it away? For an intelligent human it's not so difficult to find out whether an m2ts file can be dropped or not, but for a computer program it's much more difficult. I fear that if I simply drop the first m2ts file if it has different audio track properties, then I might damage some real movies.

Thoughts?

(BTW, the frame rate is not different, eac3to is more or less "guessing" the m2ts framerate, it's sometimes wrong. The video track framerate is reliable and it's identical.)

[madshi]

eac3to v3.23 released

http://madshi.net/eac3to.zip

* fixed: handling of MKV files with header compression didn't work
* fixed: track listing of some Blu-Rays failed silently
* added support for decoding mono tracks with ArcSoft DTS decoder
* added reading support for DTS tracks with additional DTS-HD header
* improved m2ts framerate detection
* video bitdepth is displayed now, if different than 8 bits
* chroma format is displayed now, if different than 4:2:0

[b66pak]

thanks a lot...

Thoughts?

keep it as it is...or you will open a pandora box!..
_

[Thunderbolt8]

thanks for the new version again :)

a few questions: what would be the problem if you left all those small .m2ts files listed? a overly long amount of different playlists? is there maybe any way to say that eac3to should list, and not cut away, all small .m2ts files of certain playlists only, e.g. such playlists which contain the 2-3 biggest .m2ts files? (sometimes, there are extras on a BD which are bigger than the actual movie)

regarding audio, so dtsma mono tracks should work now. so whats still left that doesnt work properly? what about those 6.1 dtsma/truehd/lpcm tracks? 2.0 dtsma? anything with "strange setup"? dts express afaik was a problem of non-existing mkvmerge support.

what are those dts-hd tracks with additional header, what does it mean? again, do we have to do any re-demuxing of our dtsma track collection to have compability with hardware receivers when just bitstreaming the file?

thanks!

[madshi]

a few questions: what would be the problem if you left all those small .m2ts files listed? a overly long amount of different playlists?
There are many Blu-Rays with literally hundreds of playlists. You'd be burried by useless information.

is there maybe any way to say that eac3to should list, and not cut away, all small .m2ts files of certain playlists only
No.

regarding audio, so dtsma mono tracks should work now. so whats still left that doesnt work properly? what about those 6.1 dtsma/truehd/lpcm tracks? 2.0 dtsma? anything with "strange setup"?
The only problem I'm aware of are those 7.1 tracks listed as "strange setup". Everything else, including mono, stereo and 6.1 should work perfectly, if you use the right ArcSoft decoder version (e.g. 1.1.0.0 works fine).

what are those dts-hd tracks with additional header, what does it mean?
If you don't know what it means that you don't need it. No need to re-demux anything.

[Thunderbolt8]

If you don't know what it means that you don't need to do it. No need to re-demux anything.well, I dont have a HD receiver yet, so I wouldnt know if I needed it ;) but if I had to redo something then I'd like to have done that by the time I have that kind of receiver, thats why I ask.

There are many Blu-Rays with literally hundreds of playlists. You'd be burried by useless information.


No.would it be possible that eac3to leaves a message when it cuts away some small parts of those playlists it displays? then you dont have to check the playlist of the main movie manually each time for those files, but only if they are really included in the list for that movie.

[mrr19121970]

Thoughts?

(BTW, the frame rate is not different, eac3to is more or less "guessing" the m2ts framerate, it's sometimes wrong. The video track framerate is reliable and it's identical.)

The answer would be 'depends' on what you want to do ultimately (have all streams separetly demuxed, have 1 .ts/.m2ts/.mkv file, or the full BD structure).

Are you (Atak_Snajpera) looking to simply demux the playlist, or recode the audio? There are a few options available currently:

Use 00014.m2ts instead of 00014.mpls for example
Use another tool (eg tsMuxeR) on each .m2ts and then correct the playlist (http://clownbd.com/Clown_BD%20MPLS%20Builder.exe).

[Snowknight26]

I think I got a fix for this one. Could you please try with the next eac3to build and report back?

Seems to be working beautifully, thanks.

[madshi]

eac3to v3.24 released

http://madshi.net/eac3to.zip

* fixed: m2ts framerate detection for h264 tracks was half of what it should be
Oooooops.

[jj666]

Hello Madshi,

I tested the new processing .DTSHD functionality, it seems to be working with all the files I threw at it so far.

However, I found that demuxing a .DTSHD file introduced a 21ms delay to the file.

I verified by demuxing the original WAV, demuxing the encoded WAV with DTS Stream Player (both matched perfectly) and demuxing with EAC3TO (+21ms added). Waveforms were checked with Adobe Audition.

FYI, before EAC3TO added this functionality, I was demuxing the .DTSHD files with TSMUXER, TSMUXER mentioned "bad frame found, resycning stream" - this also introduced the same +21ms delay.

Cheers,

-jj-

[Thunderbolt8]

However, I found that demuxing a .DTSHD file introduced a 21ms delay to the file.when you demux it from what? you also get a delay now when demuxing it from the original blu-ray source?

[madshi]

However, I found that demuxing a .DTSHD file introduced a 21ms delay to the file.

I verified by demuxing the original WAV, demuxing the encoded WAV with DTS Stream Player (both matched perfectly) and demuxing with EAC3TO (+21ms added). Waveforms were checked with Adobe Audition.

FYI, before EAC3TO added this functionality, I was demuxing the .DTSHD files with TSMUXER, TSMUXER mentioned "bad frame found, resycning stream" - this also introduced the same +21ms delay.
I think the delay is probably caused by the encoder. The "demuxing" (= removal of added DTS-HD header structure) should not have any effect on the audio data or the delay.

[Thunderbolt8]

yes, seems like it. did a waveform comparison of the center channel of

blu-ray source -> flac -> wavs and
blu-ray source -> demuxed dtsma -> flac -> wavs

and both are exactly the same with no delay.

[tebasuna51]

Thanks madshi.

Very good fixes.

[madshi]

Pleasure... :)

[ACrowley]

* added reading support for DTS tracks with additional DTS-HD header

Thank you :) A restore/add additional DTSHD Header Function would complete it :)

[madshi]

A restore/add additional DTSHD Header Function would complete it :)
Not going to happen, at least not anytime soon. There's no specification about how the headers need to look like and there are lot of fields in there that need to be filled (e.g. sampling rate etc). I'm not going to write guessed headers. That would only open up a can of worms. A lot of follow up bugs would probably show up, and I neither have the fun nor the time to spend week after week trying to do all the necessary bugfixes... :(

[AnryV]

I've checked this and all decoders output the same volume - even libav which definitely doesn't do dialnorm processing for DTS when eac3to removes it from the headers. I believe that the volume was already changed (hard coded) by the DTS encoder. And I believe that ArcSoft totally ignores the dialnorm when decoding.

One key information is that decoding the track with ArcSoft and Sonic decoders output bit perfect identically results. Which means that decoding should be lossless which would not be the case if dialnorm processing was active.

http://thumbnails30.imagebam.com/9335/2de43b93341946.jpg (http://www.imagebam.com/image/2de43b93341946)

eac3to -test
eac3to (v3.22) is installed
Nero Audio Decoder (Nero 7) works fine
ArcSoft DTS Decoder (1.1.0.1) works fine
Sonic Audio Decoder (4.3.0.169) works fine
Haali Matroska Muxer (2009-01-11) is installed
Nero AAC Encoder (1.3.3.0) is installed
Surcode DTS Encoder (1.0.29.0) is installed
MkvToolnix (2.9.9.0, release version) is installed

[jj666]

yes, seems like it. did a waveform comparison of the center channel of

blu-ray source -> flac -> wavs and
blu-ray source -> demuxed dtsma -> flac -> wavs

and both are exactly the same with no delay.

That right, but that wasn't anything at all to do with my question.

Cheers,

-jj-

[jj666]

I think the delay is probably caused by the encoder. The "demuxing" (= removal of added DTS-HD header structure) should not have any effect on the audio data or the delay.

Process:
- I demuxed a two channel .WAV and encoded to DTS-HD MA.
- Demuxing (or rather splitting the outputted .DTSHD) to individual .WAVs with DTS StreamPlayer results in an identical to
original source file when compared to original in Adobe Audition.
- Demuxing (or rather splitting the outputted .DTSHD) to individual .WAVs with EAC3TO results in an file with +21ms delay when compared to original in Adobe Audition.

Cheers,

-jj-

[madshi]

http://thumbnails30.imagebam.com/9335/2de43b93341946.jpg
You're right, my fault, must have made a mistake when testing. I've now done some more checks. The problem is that whenever I try to manipulate the DTS-HD headers, the ArcSoft DTS decoder seems to ignore the DTS-HD information. I guess that there's a CRC somewhere in the headers which I'd need to update, but I don't know where it is nor how to update it. So it seems that my hands are tied here.

Ergo: If you have a DTS-HD track with dialnorm in it, ArcSoft will honor the dialnorm, while Sonic ignores it. Nothing I can do about it, it seems. Fortunately DTS tracks with dialnorm in it seem to be pretty rare...