View Full Version : eac3to - audio conversion tool
Chouonsoku
27th August 2010, 04:28
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
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
...
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
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
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?
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
It's a know bug of v1.1.0.7, use v1.1.0.0 for DTS-MA 6.1Do 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
:confused:
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
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 eac3toThanks! I will see how easy/hard this and report back.
7ekno
5th September 2010, 11:21
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) ..
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) ...
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
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. :)
Frogger13
7th September 2010, 18:22
I want to UP this Issue as I'm getting the same since I moved from version 3.22 to 3.24. Happens especially when under heavy load (e.g. multiple encodings at the same time) but also spuriously when encoding one file at a time :(
I've been having a problem with eac3to and NeroAACEnc with later versions of eac3to. After encoding the decoded WAV, the log says that NeroAACEnc seems to be stuck (but I've no clue as to why) and it starts to encode the file again. I don't remember at which point the problem started to occur but it hasn't been there for long.
eac3to v3.24
command line: c:\utils\eac3to\eac3to.exe "e:\temp\dvd-rip\star trek tng\4x17 T81 3_2ch 384Kbps DELAY 0ms.ac3" "f:\temp\captures\tng_4x17_audio.m4a" -quality=0.42 -normalize -down2
------------------------------------------------------------------------------
AC3, 5.1 channels, 0:43:41, 384kbps, 48kHz, dialnorm: -27dB
Disabling DRC for Nero (E-)AC3 decoding...
Removing AC3 dialog normalization...
Decoding with DirectShow (Nero Audio Decoder 2)...
DirectShow reports 5.1 channels, 24 bits, 48kHz
Downmixing multi channel audio to stereo...
Writing WAV...
Creating file "f:\temp\captures\tng_4x17_audio.m4a.pass1.wav"...
Starting 2nd pass...
Reading WAV...
Reducing depth from 64 to 32 bits...
Encoding AAC <0.42> with NeroAacEnc...
Applying 3,6dB gain...
The original audio track has a constant bit depth of 64 bits.
The processed audio track has a constant bit depth of 32 bits.
The Nero AAC encoder seems to be stuck... <ERROR>
[NeroAacEnc] Processed 0 seconds...
[NeroAacEnc] Processed 1 seconds...
[NeroAacEnc] Processed 2 seconds...
[NeroAacEnc] Processed 3 seconds...
[NeroAacEnc] Processed 4 seconds...
[NeroAacEnc] Processed 5 seconds...
[NeroAacEnc] Processed 6 seconds...
[NeroAacEnc] Processed 7 seconds...
[NeroAacEnc] Processed 8 seconds...
[NeroAacEnc] Processed 9 seconds...
[NeroAacEnc] Processed 10 seconds...
[NeroAacEnc] Processed 11 seconds...
[NeroAacEnc] Processed 12 seconds...
[NeroAacEnc] Processed 13 seconds...
[NeroAacEnc] Processed 14 seconds...
[NeroAacEnc] Processed 15 seconds...
[NeroAacEnc] Processed 16 seconds...
[NeroAacEnc] Processed 17 seconds...
[NeroAacEnc] Processed 18 seconds...
[NeroAacEnc] Processed 19 seconds...
[NeroAacEnc] Processed 20 seconds...
[NeroAacEnc] Processed 21 seconds...
.
.
.
.
[NeroAacEnc] Processed 2531 seconds...
[NeroAacEnc] Processed 2532 seconds...
[NeroAacEnc] Processed 2533 seconds...
[NeroAacEnc] Processed 2534 se
Aborted at file position 2012946500. <ERROR>
Thunderbolt8
9th September 2010, 12:46
whats the status on the framerate recognition thing in case of movies which consist of more than 1 .m2ts file? is it considered a problem if that value is estimated wrong at the stage of parsing? got a case here in which both .m2ts files have the same framerate, but the complete playlist is nevertheless estimated wrongly.
edit: for the same movie I got problems with the subtitles of those combined .m2ts files. its ok with another program, but this problem does not occur at all when just using the subs from the main .m2ts file alone.
mastrandrea
11th September 2010, 18:06
I'm trying to slow down a 4 channel ac3, but eac3to return this error:
The AC3 encoder received a non-supported data format (float, 4, 64, -).
Aborted at file position 262144.
Am I doing somethig wrong?
Here's the mediainfo log for this particular track:
Audio
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Duration : 1h 29mn
Bit rate mode : Constant
Bit rate : 384 Kbps
Channel(s) : 4 channels
Channel positions : Front: L C R, Side: C
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Stream size : 245 MiB (100%)
Thanks in advance!
Snowknight26
11th September 2010, 20:16
Am I doing somethig wrong?
Apart from not searching beforehand, no.
http://forum.doom9.org/showthread.php?p=1412746#post1412746
tebasuna51
11th September 2010, 20:39
Use eac3to and a 'pipe' to Aften.exe
eac3to input stdout.wav -slowdown | Aften -b 384 -readtoeof 1 - output.ac3
Thunderbolt8
13th September 2010, 18:50
when using -slowdown, to which fps rate does eac3to actually slow down, to 23.976 or precisely to 24/1.001? and when having normal source blu-rays with 23.976 audio and video, is it 24/1.001 here as well or just 23.976?
(basically Im asking when trying to combine track from different releases, if there could be a very slight sync problem in cases there are difference between source and slowed tracks due to that)
and in that respect I got a 7.1 blu-ray track here:
eac3to v3.24
command line: eac3to H:\express.flac H:\expressslowed.flac -24.000 -slowdown
------------------------------------------------------------------------------
FLAC, 7.1 channels, 1:42:14, 16 bits, 977kbps, 48kHz
Decoding FLAC...
Changing FPS from 24.000 to 23.976...
Reducing depth from 64 to 24 bits...
Encoding FLAC with libFlac...
Creating file "H:\expressslowed.flac"...
Clipping detected, a 2nd pass will be necessary. <WARNING>
The original audio track has a constant bit depth of 16 bits.
The processed audio track has a constant bit depth of 24 bits.
Starting 2nd pass...
Decoding FLAC...
Changing FPS from 24.000 to 23.976...
Reducing depth from 64 to 24 bits...
Encoding FLAC with libFlac...
Applying -0,38dB gain...
Creating file "H:\expressslowed.flac"...
The processed audio track has a constant bit depth of 24 bits.
eac3to processing took 50 minutes, 35 seconds.
Done.
doesnt clipping usually only occur with hdtv caps? and has that anything to do with those -0,5dB gain? or why else must gain have been applied (the 7.1 source was a DTS-HD MA track with strange setup btw.)
regarding that 7.1 strange setup, I only get that note in combination with the audio of the complete blu-ray structure. when I demux that track, that information is gone. so is some kind of information now lost regarding channel setup when I want to transform that demuxed track into another audio format, would audio channels or the converted content be different compared to when using the source audio within its blu-ray structure?
if so, is it maybe to fix this with a kind of -switch which assumes the source uses such a kind of setup or maybe adding that information to the demuxed dtsma track header?
dansrfe
13th September 2010, 19:49
Does eac3to do timestreching or just a simple slowdown or speedup neglecting pitch etc.?
TinTime
13th September 2010, 21:37
doesnt clipping usually only occur with hdtv caps?
Clipping can occur when re-sampling, as is happening here.
tebasuna51
14th September 2010, 00:35
when using -slowdown, to which fps rate does eac3to actually slow down, to 23.976 or precisely to 24/1.001?
24/1.001
and when having normal source blu-rays with 23.976 audio and video, is it 24/1.001 here as well or just 23.976?
24/1.001
doesnt clipping usually only occur with hdtv caps?
Can occur with any lossy conversion, like here changing audio duration.
and has that anything to do with those -0,5dB gain?
Is only a info (that I request to madshi).
Thunderbolt8
14th September 2010, 02:51
24/1.001
Can occur with any lossy conversion, like here changing audio duration.I used it on a flac file, so after a slowdown (or speedup) the audio quality, aside from the lost or gained pitch, is not lossless any more?
TinTime
14th September 2010, 04:34
I used it on a flac file, so after a slowdown (or speedup) the audio quality, aside from the lost or gained pitch, is not lossless any more?
No, it's been re-sampled - not (usually) a lossless procedure. The only way to keep it lossless in this case would be to play the original track slower and have a DAC that handles a (48000/1.001)kHz sample rate.
Thunderbolt8
15th September 2010, 05:00
has anyone already made experiences with that low volume problem of those dtsma strange setup 7.1 channels? is the volume still evenly distributed over the channels like normal, just lower now, so that cranking up the volume solves the problem? are there any other problems aside the volume thing which could come along when trying to transform to 7.1 flac? (only have a 5.1 system, so I cannot really test whether all the channels are correct)
xkodi
15th September 2010, 13:13
has anyone already made experiences with that low volume problem of those dtsma strange setup 7.1 channels? ...
Sonic DTS decoder correctly and bit-perfectly decodes DTS-HD MA 7.1 with "strange setup" to 5.1 channels.
so, it's your choice: get bit-perfect and correct 5.1 channels from your DTS-HD MA 7.1 with "strange setup" using Sonic DTS decoder or get 7.1 channels with using Arcsoft decoder, but all of those 7.1 channels are not-bit-perfectly decoded and since at least to me it's not clear exactly what processing of the audio data Arcsoft decoder is doing in case of "strange setup" we can even assume they are wrong.
so, at least in my opinion the safest way to go is using Sonic DTS decoder in such case of "strange setup" DTS-HD MA 7.1.
for the sake of completeness i can elaborate a little more with listing the facts:
1. "normal" (not "strange setup") DTS-HD MA 7.1 has the following channel layout:
http://thumbnails31.imagebam.com/9780/43bb3497794528.jpg (http://www.imagebam.com/image/43bb3497794528)
which in the way how Microsoft (and thus eac3to) named the channels is the same as:
http://thumbnails30.imagebam.com/9780/160e7497795034.jpg (http://www.imagebam.com/image/160e7497795034)
or DTS channel names mapped to Microsoft channel names are as follows:
DTS channel name <---> Microsoft channel name
L <---> L
R <---> R
C <---> C
LFE <---> LFE
Lsr <---> BL
Rsr <---> BR
Lss <---> SL
Rss <---> SR
2. "strange setup" DTS-HD MA 7.1 has the following channel layout:
http://thumbnails28.imagebam.com/9780/da2a3097795712.jpg (http://www.imagebam.com/image/da2a3097795712)
or using the way how Microsoft (and thus eac3to) named the channels then DTS channel names mapped to Microsoft channel names are as follows:
L <---> L
R <---> R
C <---> C
LFE <---> LFE
Lsr <---> BL
Rsr <---> BR
Ls <---> i don't know how it's called in Microsoft terms
Rs <---> i don't know how it's called in Microsoft terms
3. DTS-HD MA 5.1 has the following channel layout:
http://thumbnails30.imagebam.com/9780/addcf997797266.jpg (http://www.imagebam.com/image/addcf997797266)
which is the same as "strange setup" DTS-HD MA 7.1 layout with missing "Lsr" (or "BL" in MS terms) and "Rsr" (or "BL" in MS terms)
4. with using Sonic DTS decoder for "normal" (not "strange setup") DTS-HD MA 7.1 you get the following 5.1 channels:
L <---> L
R <---> R
C <---> C
LFE <---> LFE
Lsr <---> not decoded
Rsr <---> not decoded
Lss <---> SL
Rss <---> SR
which even that are bit-perfectly decoded are not the correct 5.1 channel configuration according to 3., because you're missing "Ls" and "Rs" channels that are used in DTS-HD MA 5.1 channel configuration as it's shown in 3., i.e. you can't convert correctly "normal" (not "strange setup") DTS-HD MA 7.1 to 5.1 channels with just using Sonic DTS decoder and actually you don't even need that, because Arcsoft gives 7.1 channels bit-perfectly decoded in case of "normal" (not "strange setup") DTS-HD MA 7.1.
5. with using Sonic DTS decoder for "strange setup" DTS-HD MA 7.1 you get the following 5.1 channels:
L <---> L
R <---> R
C <---> C
LFE <---> LFE
Lsr <---> not decoded
Rsr <---> not decoded
Ls <---> decoded, but i don't know how it's called in Microsoft terms
Rs <---> decoded, but i don't know how it's called in Microsoft terms
or you have 5.1 channels bit-perfectly decoded and also they are:
L, R, C, LFE, Ls, Rs
which is the correct configuration for DTS-HD MA 5.1 channels according to 3.
so, in very short: DTS-HD MA 7.1 with "strange setup" can be decoded bit-perfectly to correct 5.1 channels and i'm not sure why "eac3to" doesn't inform the user about it and even do that by default, because at least in my opinion it's much proper way than using Arcsoft. also, because of those facts it's correct to say that you can think in case of DTS-HD MA 7.1 with "strange setup" that you actually have DTS-HD MA 5.1, because that is what information you can extract correctly and bit-perfectly from it.
nautilus7
15th September 2010, 15:13
Thanks, xkodi. So you can use sonic to get (correct) 5.1 ch and arcsoft to get the (not correct) extra 2 ch and combine them in an audio editor to reach 7.1 ch.
Midzuki
15th September 2010, 16:26
Sonic DTS decoder correctly and bit-perfectly decodes DTS-HD MA 7.1 with "strange setup" to 5.1 channels.
:thanks: 4 sharing that info.
...
or get 7.1 channels with using Arcsoft decoder, but all of those 7.1 channels are not-bit-perfectly decoded and since at least to me it's not clear exactly what processing of the audio data Arcsoft decoder is doing in case of "strange setup" we can even assume they are wrong.
FWIW, and for the time being, I have confirmed that ArcSoft doesn't decode stereo lossless-DTS correctly. :(
Ls <---> i don't know how it's called in Microsoft terms
Rs <---> i don't know how it's called in Microsoft terms
Ls == Back-Left
Rs == Back-Right
Besides, Lsr and Rsr "do not exist" in the Wave-Format-Extensible "universe"
( and if they existed, they would be called
"Back Left of Center" && "Back Right of Center" ).
Thunderbolt8
15th September 2010, 18:42
is it really bit-perfect, meaning that the information from those 2 other channels is then added somewhere to the front or side channels of 5.1? or is that information from those 2 channels dropped (because you said "not decoded", which would not be bit-perfect then compared to the source information)?
and in case its added to the 5.1 channels, is there any way to measure how good it would sound compared to the same sound recorded and distributed to 5.1 only in the first place (so how accurate is the distribution of those 2 non decoded channel to the 5.1 channels)?
xkodi
15th September 2010, 19:05
So you can use sonic to get (correct) 5.1 ch and arcsoft to get the (not correct) extra 2 ch and combine them in an audio editor to reach 7.1 ch.
yes, if you want 7.1 channels that's one way to lower the error, but still you won't get completely correct 7.1 channels as in case if you go for just 5.1 channels.
one other possibility to lower error maybe is to use "Ls" and "Rs" to calculate from them new "Lsr" and "Rsr", because according to:
http://thumbnails28.imagebam.com/9780/da2a3097795712.jpg (http://www.imagebam.com/image/da2a3097795712)
they seem on very close positions to each other and "tebasuna51" is very good in making such calculation. however, it's just an idea, because i don't know if new "Lsr" and "Rsr" made in such way will be better than what Arcsoft is decoding for "Lsr" and "Rsr".
Ls == Back-Left
Rs == Back-Right
Besides, Lsr and Rsr "do not exist" in the Wave-Format-Extensible "universe"
( and if they existed, they would be called
"Back Left of Center" && "Back Right of Center" ).
thanks, it's very confusing, because it seems to me in 5.1 channels configuration:
DTS Ls == MS BL
DTS Rs == MS BR
but in 7.1 channel configuration:
DTS Lsr == MS BL
DTS Rsr == MS BR
or maybe i'm wrong again - at least that's what i can conclude from the picture in my initial post - i took all of those pictures from DTS and MS.
is it really bit-perfect, meaning that the information from those 2 other channels is then added somewhere to the front or side channels of 5.1? or is that information from those 2 channels dropped (because you said "not decoded", which would not be bit-perfect then compared to the source information)?
i'm not sure that i understand what you're asking, but let me try to explain it again in different way:
* "strange setup" DTS-HD MA 7.1 decoded with Arcsoft: all 7.1 channels are decoded, but not any of those 7.1 channels is decoded bit-perfectly, which means not lossless and thus it's not correct, because DTS-HD MA is lossless. how wrong Arcsoft decodes them is not clear at least to my knowledge, because it's not clear what kind of processing of the audio data Arcsoft does in the case of "strange setup" DTS-HD MA 7.1.
* "strange setup" DTS-HD MA 7.1 decoded with Sonic: only 5.1 channels are decoded from the initial 7.1 channels, but those 5.1 channels are decoded:
- in bit-perfectly way, i.e. lossless
- as correct set of channels for 5.1 configuration, because what you get of decoding with Sonic is: (L, R, C, LFE, Lsr, Rsr, Ls, Rs) are reduced to (L, R, C, LFE, Ls, Rs) and so there is no any loss of information for 5.1 channel setup
or as i tried to summarize it my initial post "strange setup" DTS-HD MA 7.1 decoded with Sonic is way to convert that to 5.1 channel configuration without any loss of audio data for 5.1 channel setup. so, if you have movie with "strange setup" DTS-HD MA 7.1 better think of it the audio is DTS-HD MA 5.1, because there is no way to get more of it on computer.
i don't if this way of explaining is more clear or not.
and in case its added to the 5.1 channels, is there any way to measure how good it would sound compared to the same sound recorded and distributed to 5.1 only in the first place (so how accurate is the distribution of those 2 non decoded channel to the 5.1 channels)?
if you're talking about what "nautilus7" there is no way to know, because we don't know what Arcsoft is doing wrong, that's why the safest way is just get 5.1 which are at least bit-perfect/lossless and correct set of channels for 5.1 - for example even if assume we can get all channels of "strange setup" DTS-HD MA 7.1 decoded bit-perfectly then on 5.1 channel system "Lsr" and "Rsr" will be stripped and that's clear form DTS channel layout in 2. and 3. in my initial post.
Thunderbolt8
15th September 2010, 19:18
so its basically like theres 2 kind of channel setup information stored for the same audio content, one for 7.1 strange setup and one for normal 5.1, and sonic chooses the 5.1 setup then?
my 2nd question basically was whether that XX channel information was added arbitrarily to those 5.1 channels. but if theres another mask available which also takes all the information into consideration from the same source sound, only this time distribution is 5.1 instead of 7.1, then I guess it should sound as if that source sound was recorded to 5.1 channels only in the first place.
can I use the same procedure also for normal 7.1 dtsma tracks, those without strange setup? or is there nothing like 5.1 channel distribution information available for sonic then?
btw. ive had 24-bit 7.1 tracks which then got transformed to 16-bit 5.1 with sonic, is it still lossless?
FWIW, and for the time being, I have confirmed that ArcSoft doesn't decode stereo lossless-DTS correctly. :(hm where? does at least sonic do it correctly?
Midzuki
15th September 2010, 19:44
Just for the record, these are the only "7.1 DTS channel layouts" which are compatible with the Wave-Format-Extensible definitions:
L, R, C, LFE, Ls, Rs, Lw, Rw
L, R, C, LFE, Ls, Rs, Cs, Ch
(Cs == Back Center, Ch == Top Front Center)
L, R, C, LFE, Ls, Rs, Cs, Oh
(Oh == Top Center)
L, R, C, LFE, Ls, Rs, Lh, Rh
(Lh == Top Front Left, Rh == Top Front Right)
Argh!
Anacletus
16th September 2010, 10:14
I want to UP this Issue as I'm getting the same since I moved from version 3.22 to 3.24. Happens especially when under heavy load (e.g. multiple encodings at the same time) but also spuriously when encoding one file at a time :(
I'm also experiencing this problem lately on many of my audio encodes, sources varies from flac to dts/dtshd.. neroaacenc abort the encoding after a while.. any clues?
flebber
18th September 2010, 14:51
Hi. Having an issue with subs being extracted by eac3to. Seems to have an error passing bitstream. I inputted a Mkv file made with Makemkv into Megui HD Streams Extracto.
Initial post in Megui Thread here, referred here as error appeared in eac3to process http://forum.doom9.org/showthread.php?p=1444148#post1444148
I have uploaded a small sample which casues the error.
http://www.mediafire.com/file/87sp8re9edx8te0/Snow%20White%20%26%20The%20Seven%20Dwarves%20%281%29-001.mkv
buzzqw
18th September 2010, 18:43
eac3to is unable to extract properly vobsub from mkv
(that why in HDC now i use mkvextract...)
BHH
xkodi
19th September 2010, 16:00
can I use the same procedure also for normal 7.1 dtsma tracks, those without strange setup? or is there nothing like 5.1 channel distribution information available for sonic then?
in very short - you can't use what i explained for "normal 7.1 dtsma tracks" (i.e. the one that are not "strange setup"). the reason for that is simple:
- channels inside "strange setup" 7.1 dtsma track are the set (L, R, C, LFE, Lsr, Rsr, Ls, Rs) and sub-set of (L, R, C, LFE, Ls, Rs) is what you need for proper 5.1 channels and exactly that set (L, R, C, LFE, Ls, Rs) is what Sonic decodes bit-perfectly from such track and that's why using Sonic you end up with bit-perfect and correct set of channels for 5.1
- channels inside "normal 7.1 dtsma tracks" are the set (L, R, C, LFE, Lsr, Rsr, Lss, Rss) and so there is no "Ls" and "Rs" that you need for 5.1 and using Sonic you will end up with 5.1 channels that are simple not the set of channels you need for proper 5.1.
btw. ive had 24-bit 7.1 tracks which then got transformed to 16-bit 5.1 with sonic, is it still lossless?
if the track is 24-bit for sure (and not 16-bit padded with "0" to 24-bit) then of course 24->16 is not lossless operation.
hm where? does at least sonic do it correctly?
i don't know, but i will check that when have some spare time.
Thunderbolt8
19th September 2010, 16:10
alright, thanks!
SLKabaker
21st September 2010, 02:26
I am relatively new to Video Conversion. I have only been doing it for a couple months now. I purchased ArcSoft MediaConverter 7. It includes the same DTS Decoder that comes with ArcSoft TMT. Is there a way to get eac3to to recognize that? I registered ASAudioHD.ax (using regsvr32) in the directory it was installed to. However, when I run eac3to -test, it still does not detect it. I ran GraphEdit, and it sees that the ArcSoft Audio Decoder is a DirectShow CODEC. I would appreciate any help in how to get eac3to to use the DTS Decoder. Do I need to copy the files and put them in another directory? I am running Windows 7 64Bit.
Also, for those of us unable to purchase Nero 7, as they are up to Nero 10 now, is it possible for eac3to to be updated to use ArcSoft's AC-3/E-AC3 decoder. It does not support Dolby TrueHD but it does support 7.1 Dolby Digital Plus. As well as, for AAC, Nero gives away free its Nero AAC Encoder and Decoder. eac3to already uses the NeroAACEncoder.exe, is there a way to have it use NeroAACDecoder.exe instead of Nero 7? Also, Microsoft put a Full E-AC3 Decoder into Windows 7...
I am sorry if any of this is already explained in the 500+ pages of this forum. Please just point me in the right direction and I will learn quickly. Thank you for all your help.
Midzuki
21st September 2010, 02:55
@ SLKabaker:
http://forum.doom9.org/showthread.php?t=148324
IMPORTANT: don't forget the file checkactivate.dll.
Thunderbolt8
21st September 2010, 03:15
afaik madshi wont bother to implement 7.1 DD+, because DD+ died when HD DVD died and there wasnt really any movie which used 7.1 DD+.
mr.duck
23rd September 2010, 02:03
Is there anything that can be done to reduce audio sync issues with eac3to? It usually happens when I get a message like this...
v01 The MKV file was created without making use of the gap/overlap information.
v01 Please check whether audio is in sync. If it is in sync everything is fine.
v01 Otherwise ask eac3to to repeat the muxing. It will then automatically make
v01 use of the detailed gap/overlap information.
If I don't repeat the muxing then sometimes the audio can be really badly out of sync. It is not predictable how much. If I repeat the muxing as it says, it successfully makes the new MKV file without this error message. But then the audio goes out of sync by a small but very noticeable amount.
So repeating the muxing does do something but maybe eac3to needs extra help by having the file cleaned up by another program that can take care of the gaps etc before passing it on to eac3to? Any other ideas how I can stop the audio going out of sync?
Mark_A_W
23rd September 2010, 12:23
I'm having terrible trouble with the last 4 Seamless Branching BD discs I've done.
The lipsync is all over the place - the audio does not match the video.
I've tried with 3.22 and 3.24. It's running the second pass, but the result is wrong. I'm converting the audio to Flac.
Has anyone else had this problem?
Thunderbolt8
23rd September 2010, 13:19
afaik never had these problems with BDs since it was working correctly.
flac's framelength is 1ms, so there shouldnt be any delay at all.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.