eac3to - audio conversion tool [Archive] - Page 271

tebasuna51

4th October 2015, 11:34

Now the .mpls I'm coming up with is 407. However, when I tried to run it, I still get this:

eac3to v3.29
command line: "J:\Blue Ray Ripping\Tools\eac3to\eac3to.exe" "J:\Rip\INSURGENT\" 110) ...
3: "J:\Temp\RipBot264temp\job2\audio_1_English.thd.w64" -down16
...
3: TrueHD (Atmos), English, 7.1 channels, 48kHz
...
[a03] The libav decoder reported error -1094995529 while decoding. <ERROR>
Aborted at file position 1048576. <ERROR>
Sometimes there are a .m2ts (maybe a initial credit because the low file position at abort) with a different format for first audio track.
This is allowed in a BD data structure but eac3to can't decode that properly.

Then you need check all .m2ts (at last the first ones) in 407.mpls to see if first audio track is always TrueHD (Atmos), English, 7.1 channels, 48kHz

a) If aren't the same you need extract/decode that track in each .m2ts.
For instance if:
110) 00407.mpls, 1:59:00
[1520+1528+1521+1529+1522+1530+1523].m2ts
and the 01521.m2ts have a different track than the rest, you can run (in J:\Rip\INSURGENT\BDMV\STREAM folder to avoid long paths)

"J:\Blue Ray Ripping\Tools\eac3to\eac3to.exe" 01520.m2ts+01528.m2ts 2) 1.w64
"J:\Blue Ray Ripping\Tools\eac3to\eac3to.exe" 01521.m2ts 2) 2.w64
"J:\Blue Ray Ripping\Tools\eac3to\eac3to.exe" 01529.m2ts+01522.m2ts+01530.m2ts 2) 3.w64

And after concatenate the 3 w64

b) If all have same format, you can try extract the .thd and after use the last ffmpeg version to see if the decoder was improved to support that problem.

ScottJ

4th October 2015, 18:34

Then you need check all .m2ts (at last the first ones) in 407.mpls to see if first audio track is always TrueHD (Atmos), English, 7.1 channels, 48kHz

What I found is that every m2ts except the last looks like this:

M2TS, 1 video track, 5 audio tracks, 3 subtitle tracks, 0:04:53, 24p /1.001
1: h264/AVC, 1080p24 /1.001 (16:9)
2: TrueHD (Atmos), English, 7.1 channels, 48kHz
3: AC3 Surround, English, 2.0 channels, 224kbps, 48kHz
4: AC3 Surround, English, 2.0 channels, 224kbps, 48kHz
5: AC3, Spanish, 5.1 channels, 640kbps, 48kHz
6: AC3 Surround, English, 2.0 channels, 224kbps, 48kHz
7: Subtitle (PGS), English
8: Subtitle (PGS), English
9: Subtitle (PGS), Spanish

The last one has an extra sub-track on the TrueHD:

M2TS, 1 video track, 5 audio tracks, 3 subtitle tracks, 1:22:31, 24p /1.001
1: h264/AVC, 1080p24 /1.001 (16:9)
2: TrueHD/AC3 (Atmos), English, 7.1 channels, 48kHz
(embedded: AC3 EX, 5.1 channels, 640kbps, 48kHz)
3: AC3 Surround, English, 2.0 channels, 224kbps, 48kHz
4: AC3 Surround, English, 2.0 channels, 224kbps, 48kHz
5: AC3, Spanish, 5.1 channels, 640kbps, 48kHz
6: AC3 Surround, English, 2.0 channels, 224kbps, 48kHz
7: Subtitle (PGS), English
8: Subtitle (PGS), English
9: Subtitle (PGS), Spanish

If I try to extract the THD track all at once it says "This video conversion is not supported." If I extract only the first group, it works into .thd but fails with the -1094995529 error to .w64.

I will extract two thd files and then try ffmpeg to convert to w64 so I can then concatenate them.

ScottJ

4th October 2015, 18:55

I will extract two thd files and then try ffmpeg to convert to w64 so I can then concatenate them.

I extracted part1.thd and part2.thd:

eac3to 00510.m2ts+00509.m2ts+00506.m2ts+00502.m2ts+00504.m2ts+00508.m2ts+00505.m2ts+00511.m2ts+00501.m2ts+00507.m2ts 2: part1.thd

eac3to 00503.m2ts 2: part2.thd

But the latest ffmpeg barfs immediately on part1:

ffmpeg.exe -i part1.thd part1.wav
ffmpeg version N-75716-g061b67f Copyright (c) 2000-2015 the FFmpeg developers
built with gcc 5.2.0 (GCC)
configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-avisynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libdcadec --enable-libfreetype --enable-libgme --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libschroedinger --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable-lzma --enable-decklink --enable-zlib
libavutil 55. 2.100 / 55. 2.100
libavcodec 57. 4.100 / 57. 4.100
libavformat 57. 2.102 / 57. 2.102
libavdevice 57. 0.100 / 57. 0.100
libavfilter 6. 9.101 / 6. 9.101
libswscale 4. 0.100 / 4. 0.100
libswresample 2. 0.100 / 2. 0.100
libpostproc 54. 0.100 / 54. 0.100
part1.thd: Invalid data found when processing input

It converts part2.thd to .w64 without any trouble.

tebasuna51

4th October 2015, 20:14

What I found is that every m2ts except the last looks like this:

...
2: TrueHD (Atmos), English, 7.1 channels, 48kHz
3: AC3 Surround, English, 2.0 channels, 224kbps, 48kHz
...

I never see a BD with a TrueHD track without the embedded AC3 5.1.
AFAIK is mandatory.
For me only the last one (00503.m2ts) is correct.

Seems there are something wrong in BD or in the previous procces (rip).

r0lZ

5th October 2015, 08:04

Sometimes there are a .m2ts (maybe a initial credit because the low file position at abort) with a different format for first audio track.
This is allowed in a BD data structure but eac3to can't decode that properly.Do you know an example of such a BD?
I would like to test how it can be processed correctly.

tebasuna51

5th October 2015, 13:36

Do you know an example of such a BD?

I test this one:

Red 2 (2013) audios: English 7.1, French 5.1, English 2.0, English 2.0
134) 00674.mpls, 1:56:04 [514+505+502+509+507+513+501+510+512+506+508+504+74+515+511+503].m2ts
00514.m2ts First audio track AC3, 5.1 channels, 448kbps, 48kHz
rest.m2ts First audio track DTS Master Audio, 7.1 channels, 24 bits, 48kHz

But most the times I check spanish BD versions with original languaje, spanish and catalan. The most complete example was:

Los idus de marzo (The Ides of March, 2011) Spanish, Catalan, English
1) 00001.mpls, 1:41:23 [17+18+19+4].m2ts
00017.m2ts, 3 audio tracks RAW/PCM, 2.0 channels, 16 bits, 48kHz
00018.m2ts, without audio tracks
00019.m2ts, 3 audio tracks AC3 2.0 channels, 640kbps, 48kHz
00004.m2ts, 3 audio tracks DTS Master Audio, 5.1 channels, 16 bits, 48kHz

The 4 m2ts with different audio. I test other 12 BD's with some of this problems.

gabbett1

5th October 2015, 22:23

I got the same issue today with Insurgent Blu-ray (US retail disc) ripped through ClownBD. Playlist 407, as determined by AnyDVD HD.

I don't know why my AnyDVD won't tell me the correct .mpls

gabbett1

5th October 2015, 22:24

maybe its because the decoder doesnt know how to process the atmos track, how to downsample all its information.

Ok, if that is the case what am I supposed to do? All of the other tracks are 2.0

ScottJ

5th October 2015, 22:41

Thunderbolt8

6th October 2015, 05:05

Ok, if that is the case what am I supposed to do? All of the other tracks are 2.0just demux it without processing otherwise.

r0lZ

6th October 2015, 08:53

I test this one:

Red 2 (2013) audios: English 7.1, French 5.1, English 2.0, English 2.0
134) 00674.mpls, 1:56:04 [514+505+502+509+507+513+501+510+512+506+508+504+74+515+511+503].m2ts
00514.m2ts First audio track AC3, 5.1 channels, 448kbps, 48kHz
rest.m2ts First audio track DTS Master Audio, 7.1 channels, 24 bits, 48kHz

But most the times I check spanish BD versions with original languaje, spanish and catalan. The most complete example was:

Los idus de marzo (The Ides of March, 2011) Spanish, Catalan, English
1) 00001.mpls, 1:41:23 [17+18+19+4].m2ts
00017.m2ts, 3 audio tracks RAW/PCM, 2.0 channels, 16 bits, 48kHz
00018.m2ts, without audio tracks
00019.m2ts, 3 audio tracks AC3 2.0 channels, 640kbps, 48kHz
00004.m2ts, 3 audio tracks DTS Master Audio, 5.1 channels, 16 bits, 48kHz

The 4 m2ts with different audio. I test other 12 BD's with some of this problems.
Wow! What a mess! There is even a M2TS without audio at all! Really strange!
Can you tell me what's the content of the 4 M2TS of Los idus de Marzo? I guess the 3 first ones are short studio or distributor logos. Right?
I'll try to find an example of a BD like that myself.
Thanks!

tebasuna51

6th October 2015, 10:50

I guess the 3 first ones are short studio or distributor logos. Right?

Yep. Also the 00004.m2ts begin with some original credits, then I reject the 3 first ones and use only the 00004.m2ts.

tebasuna51

6th October 2015, 11:09

I thought that was fishy myself. But the full-disc rip plays fine in my Dune HD Base 3.0 (with full Blu-ray menus).

Maybe, but a BD must be compatible with old audio systems without THD/DTS-HD decoders. For that systems the player need send the AC3 embedded in THD track or the 'core' of DTS-HD.

r0lZ

6th October 2015, 12:07

Continuation of the discussion started here (http://forum.doom9.org/showthread.php?p=1740491#post1740491):
Can you test these samples:
https://www.sendspace.com/file/lcnqy5
OK, I have finally found some times to do more tests.

The 4 samples sneaker_ger gave me play fine with my TV. :-)

So, I've decided to try different things to reproduce the problem.

First, I have demuxed the audio from SampleA, and converted it to WAV mono (with Foobar2000) and re-encoded it to AAC in a M4A container with eac3to and the Nero encoder. Remuxed the M4A and the original video track from SampleA with MkvMerge: no problem. :-)

My next test was to re-encode also the video. I have used the same x264 settings I've used with the movie that has motived me to post here: --crf 20 --preset slower --level 4.1 --vbv-bufsize 78125 --vbv-maxrate 62500. After remux with the M4A produced during my previous test, there is no problem. :-)

Then I remembered that I had to add a large delay to the audio (exactly 5005 ms) to have the audio and video of the movie in sync. So, I've encoded an avisynth script that returns the same video but with a BlankClip of 5005 ms before the actual video. I've used the same x264 parameters than in the previous test and muxed the audio with the correct delay of 5005 ms. Bingo! The sound has a glitch at approximately 15 seconds in the file. :-(

I have then muxed the same video (with the 5 seconds of black at the beginning) but with different delays, to verify if it's only a (relatively) long delay that is responsible of the problem. I've tested with 9, 1000, 2000, 3000, 4000, 5000 and 10000 ms. All files play fine in my TV except the one muxed with 5000 ms delay! And this time, the sound is really choppy, about one glitch every 3 seconds or so.

To confirm that the problem is not related to the video encoding, I have muxed the original AVC stream from SampleA with the M4A and the delay of 5000ms, and again the sound is extremely choppy.

I just did a last test, again with the original video, but this time with the AAC track directly extracted from SampleA, and a delay of 5005 ms. The sound is choppy again. That means that I was wrong when I thought that the problem was related to the M4A container. It's AAC that causes the problem, within a M4A container or not. I don't understand why I haven't noticed the glitches when I've muxed the AAC stream with the movie, but it appears that it is not sufficient to avoid the problem by muxing only AAC elementary streams.

So it appears that the problem is caused by specific delays and an AAC/M4A audio track. 5005 ms of delay causes a single glitch near the middle of the (short) clip, and 5000 ms causes a lot of glitches. The other delays work perfectly! It's absolutely unbelievable, but it's so!

What can happen when the delay is around 5000 ms and the input file is AAC but not when the delay is different or the audio encoding is not AAC is far beyond my understanding! But according to my tests I suppose that it's a bug in MkvMerge and not in eac3to, the Nero AAC encoder, the M4A container or the x264 encoder.

End of story and sorry to have posted in this thread for a problem that appears now not related to eac3to. And thanks for your help.

tebasuna51

7th October 2015, 09:59

...I suppose that it's a bug in MkvMerge...

Or in that player. Tested that delay in PC (MPC-HC) and in my old Xtreamer player without problems.

BTW remember than you can apply delays to audio streams, replacing the delay with initial silence, with:

eac3to input.aac delayed.aac +5005ms

SeeMoreDigital

7th October 2015, 15:21

... and in my old Xtreamer player without problems.
Out of interest (and off-topic), which model?

tebasuna51

7th October 2015, 18:52

Out of interest (and off-topic), which model?
The first one.

r0lZ

8th October 2015, 10:13

Or in that player. Tested that delay in PC (MPC-HC) and in my old Xtreamer player without problems.Yes, the player in the TV may be culprit too, and it is true that all software players I've used do not exhibit that problem. But my TV can play AAC streams in all other circumstances without problem. So I guess that something happens when the delay is around 5000 ms that makes it fail decoding or playing it properly. I can't say for sure that MkvMerge is also culprit, but I suspects it. I will try to mux an M2TS with a delay of 5000 ms to see if it's accepted without problem by my TV. If only MKVs have that problem, I suppose that we can assume that the bug is in MkvMerge.

BTW remember than you can apply delays to audio streams, replacing the delay with initial silence, with:

eac3to input.aac delayed.aac +5005ms
Thanks for the tip.

Can I use exactly the same syntax with all audio formats, and particularly with all common formats of the blu-ray primary audio streams (AC3, EAC3, THD, DTS, DTSHD, DTSHDMA and LPCM)?

And is it totally secure? I have had bad results when re-encoding only certain parts of a video GOP with VideoReDo (to do frame-accurate cuts) and I wonder if the same problem can happen with audio. Since the encoder of the additional blank cannot be exactly identical to the original encoder, the silence that has been added may not have exactly the same characteristics than the original audio and that may confuse the player. What do you think? Is it really safe, even with picky players?

Xorp

8th October 2015, 20:31

I never see a BD with a TrueHD track without the embedded AC3 5.1.
AFAIK is mandatory.
For me only the last one (00503.m2ts) is correct.

Seems there are something wrong in BD or in the previous procces (rip).

The new Dracula release by Sony also does not have an embedded AC3 track in it's TrueHD/Atmos track:

M2TS, 1 video track, 6 audio tracks, 6 subtitle tracks, 2:07:22, 24p /1.001
1: Chapters, 16 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: TrueHD (Atmos), English, 7.1 channels, 48kHz
4: AC3, English, 5.1 channels, 640kbps, 48kHz
5: AC3, French, 5.1 channels, 448kbps, 48kHz
6: AC3, Spanish, 5.1 channels, 448kbps, 48kHz
7: AC3 Surround, English, 2.0 channels, 192kbps, 48kHz
8: AC3 Surround, English, 2.0 channels, 192kbps, 48kHz
9: Subtitle (PGS), English
10: Subtitle (PGS), English
11: Subtitle (PGS), French
12: Subtitle (PGS), Spanish
13: Subtitle (PGS), English
14: Subtitle (PGS), English

decoding it to FLAC failed immediately for me

a03 Decoding with libav/ffmpeg...
a03 Encoding FLAC with libFlac...
a03 The libav decoder reported error -1094995529 while decoding.
a03 Creating file "dracula - 3 - TrueHD (Atmos), English, 7.1 channels, 48kHz.flac"...
Aborted at file position 1048576.

madshi

8th October 2015, 21:11

Could be that there's an AC3 track in there which eac3to just fails to detect properly, which would also explain the problem with decoding. Might make sense to add a bug report to the eac3to bug tracker with a sample that allows to reproduce the decoding problem and the "missing" (?) AC3 track.

Ryushin

8th October 2015, 21:59

I'm a user of ripbot264. I was reading earlier this year in Marche athat Atak_Snajpera and howzz where talking about methods to improve the performance of demuxing of eac3to starting at post #13042 (http://forum.doom9.org/showthread.php?p=1712967#post1712967).

I'm not planning on adding SSD for my demuxing storage as it is not totally uncommon for me to demux over a TB of data in my queues.

I have a local 3TB drive and I also have a ZFS server running with 24 hard drives. Today I exported a 3TB iscsi lun from my ZFS server and I only saw about a 14% improvement in speed over the single drive. The ZFS server can easily write 1.4GB/s and read over 1.2GB/s. 8GB of RAM is given to the ZFS cache and ZFS streams the ordered writes every five seconds from RAM. The iscsi mount should only be limited by bandwidth, but I'm only seeing about 35MB/s during the demuxing process when a simple I/O test showed about 110MB/s available.

As howzz mentioned, the system is not working very hard during the demuxing process and the same goes for me.

madshi said at the time and for the foreseeable future he did not have time to work on diagnosing the bottleneck.

In the mean time, can anyone suggest any possible methods to speed up the demuxing process? I'm sitting on 5.25TB worth of blu-ray shows that I still have to process. and consider it takes about 7-10 minutes to demux each show, I'm going to be here for quite a while.

Boulder

9th October 2015, 05:00

Can you run multiple instances of eac3to simultaneously, or will the increase in seek time nullify the benefits?

tebasuna51

9th October 2015, 14:22

Can I use exactly the same syntax with all audio formats, and particularly with all common formats of the blu-ray primary audio streams (AC3, EAC3, THD, DTS, DTSHD, DTSHDMA and LPCM)?

And is it totally secure? I have had bad results when re-encoding only certain parts of a video GOP with VideoReDo (to do frame-accurate cuts) and I wonder if the same problem can happen with audio. Since the encoder of the additional blank cannot be exactly identical to the original encoder, the silence that has been added may not have exactly the same characteristics than the original audio and that may confuse the player. What do you think? Is it really safe, even with picky players?

Don't work with THD tracks, if you use:

eac3to sample1.thd sample2.thd +100ms

the output is bitidentical to sample1 but with the name "sample2 DELAY 100ms.thd"

With the other tracks eac3to works cutting/adding complete audio frames, never recoding the audio. Then there are a granularity in the delay allowed.

The worst case is AC3 (or EAC3 with AC3 core) than have the big framelength (32 ms) then the output can need until +- 16 ms of additional delay (can be ignored because is less than a video frame duration).

The DTS (all) framelength is over 11 ms now the error delay is less than +- 6 ms. Without problems with LPCM (framelength of 48 KHz is 0.02 ms).

Tested standars BD tracks AC3, EAC3, DTS, DTS-HR, DTS-MA and LPCM without problems.

When the delay is <0 only cut frames then can't have problems.

When the delay is >0 eac3to add silent frames. I don't know exactly how eac3to make that silent frames in all cases, but in all my test the delayed track is recognized, and decoded fine, with the same parameters than source.

Audio frames are all with the same frame structure don't exist problems like with video frames I, P and B.

Xorp

9th October 2015, 17:29

tebasuna51

9th October 2015, 21:57

BDInfo also reports no embedded track, but I'll let you take a look at it. Submitted bug report 345.

Remuxed your sample with tsMuxeR and now eac3to recognize the embedded track and work fine. Also with the full m2ts from Dracula BD.

Xorp

9th October 2015, 22:32

Remuxed your sample with tsMuxeR and now eac3to recognize the embedded track and work fine. Also with the full m2ts from Dracula BD.

Thank you for looking at it. You're right there's an AC3 track in there after remuxing with tsmuxer. So there's some funky authoring by Sony that eac3to and BDInfo don't like by default.

r0lZ

10th October 2015, 10:35

Tested standars BD tracks AC3, EAC3, DTS, DTS-HR, DTS-MA and LPCM without problems.
OK, thanks for the info. Very appreciated.

BTW, I forgot to ask if, to your knowledge, adding a (large) delay to an audio track in a MKV container can cause problems with some players (other than the problem of the choppy sound I have discovered with AAC and delays around 5000ms). For example, I wonder if some players may simply give up when they play a video file with an audio that they cannot detect during a long time.

I have the habit to add a delay of 5005 ms to the encodings of the 3D-Movies, because my TV switches automatically to 3D only 1 or 2 seconds after the start of the movie, and displays a lot of things during the first 5 seconds. That's very unpleasant, and therefore I add 5 seconds of black at the beginning of the video so that the real movie starts only after that junk. The audio must be delayed accordingly, and until now I've used the delay option of MkvMerge. It works fine, but as I have discovered, not with AAC and a delay of 5 seconds. But AAC is not a native audio format in the BDs and since I prefer the original DTS or AC3, I can ignore that problem. But anyway I wonder what is the safest method for BD3D2MK3D: Should I add a silence like you have suggested or continue to use the --delay setting of MkvMerge? For me, the second solution is much easier, and it is already implemented. Do you think that there are other reasons to avoid it ?

tebasuna51

10th October 2015, 17:30

...Do you think that there are other reasons to avoid it ?

Nope. This is the first time than I read a problem with big delays in mkv.

Long time ago using avi container and the fake delay than VirtualDub do (fill with 0's the begining of audio track to be delayed), there are some players (ie. PlayStation) than refuse the track because don't found a valid header in first data. But using mkv I never read that problem.

buffyangel108

10th October 2015, 20:01

Hi all,

I have a query about FLAC compression. From earlier in the thread, I see that eac3to uses level 8 by default (best compression, slowest encode time).

Is there any way to change this? I use FLAC files as a temporary step in my conversion process (it's the only lossless format accepted by my audio program) so speed matters more than compression.

Is there any way to specify, for example, level 0 compression for FLAC output instead? If not, could the eac3to (or libFLAC) executables be hex-edited to change the default level used?

tebasuna51

10th October 2015, 21:29

Is there any way to specify, for example, level 0 compression for FLAC output instead?

You can use the flac.exe encoder to put any parameter. For instance:

eac3to input stdout.wav | flac -o outfile.flac --ignore-chunk-sizes -0 -

ndjamena

11th October 2015, 06:34

Is it that common for TV shows to use 16-bit audio, but to signal 24-bit audio (or just to use TrueHD with a 16-bit audio source)? I don't own many TV series' BDs, so I'm curious.

Legend of Korra, Season 4.

24 bit DTS with an actual of 16 bits

Interestingly enough, season one is mostly 16 bit as well, it's just the end credits that are 24 bit. I chopped a file up and reduced both pieces to 16 bit and I can't tell there was a difference. I think season 2 is the same. Season 3 is the only season with actual 24 bit audio.

Music Fan

11th October 2015, 08:41

There is no specific quantification with compressed audio formats, 24 bit in DTS files is just a header information to tell it was compressed from a 24 bit wav, but there is no way to accurately determine original wav's quantification.

ndjamena

11th October 2015, 10:33

I'm reducing all my 24 bit tracks to 16 bit, so it pays to be picky in my current situation. At the moment I'm staggering my way through writing a program to locate 24 or 16 bit sections in a stream, it's a bit messy at the moment but I'd have never figured out it was just the end credits without it.

Maybe audacity or something would help...

Pacific Rim looks to be a problem...

DarkSpace

11th October 2015, 11:07

Legend of Korra, Season 4.

24 bit DTS with an actual of 16 bits

Interestingly enough, season one is mostly 16 bit as well, it's just the end credits that are 24 bit. I chopped a file up and reduced both pieces to 16 bit and I can't tell there was a difference. I think season 2 is the same. Season 3 is the only season with actual 24 bit audio.
Thanks. Late answer, sure, but still appreciated... I learned something new. Now that I've finally got a working BD drive, I guess I should read my Star Trek series' BDs and check what they use... as I already stated, I'm curious.

There is no specific quantification with compressed audio formats, 24 bit in DTS files is just a header information to tell it was compressed from a 24 bit wav, but there is no way to accurately determine original wav's quantification.
I agree that DTS itself is lossy, and has no specific bitdepth. From context, though, I'd guess that he meant DTS-HD MA.

I'm reducing all my 24 bit tracks to 16 bit, so it pays to be picky in my current situation. At the moment I'm staggering my way through writing a program to locate 24 or 16 bit sections in a stream, it's a bit messy at the moment but I'd have never figured out it was just the end credits without it.

For what it's worth, I could probably hack together a small script that reads raw PCM (no header) and then only executes "eac3to -down16" for >16-bit sections (simply truncating the 16-bit sections) and returns the merged output. Are you interested?

ndjamena

11th October 2015, 11:55

Yes... DTS-MA... head hurts... shorten things...

Urrgh.

Script? Is this an AVI/Vapoursynth script?

I'm still trying to figure out how to detect it automatically, at the moment it just spits out the timecode of any sample that uses more than 2 bytes.

If you write a script I could try it.

At the moment I'm wondering:
1: how eac3to detects them, it doesn't seem to think there are ANY 16 bit sections in season 3 at all, so what criteria is it using?
2: why it is that once I've down sampled the end credits to 16 bit, while simply stripping the rest it all sounds exactly the same. I was expecting the volume in the credits to be lower or something, there's no gain settings inside a wav file that I can see, am I just not hearing it?

DarkSpace

11th October 2015, 13:11

Yes... DTS-MA... head hurts... shorten things...

Urrgh.
Do remember to take breaks... I notice on myself that when I start having strange delusions about impossible stuff, I should think about other things for a while, because any code I write in that state, I will have to re-write when I'm more awake anyway.

Script? Is this an AVI/Vapoursynth script?
It's probably going to be a simple python script or something like that. There's no gain in using AVS/VS for this anyway, the way I see it right now.

At the moment I'm wondering:
2: why it is that once I've down sampled the end credits to 16 bit, while simply stripping the rest it all sounds exactly the same. I was expecting the volume in the credits to be lower or something, there's no gain settings inside a wav file that I can see, am I just not hearing it?
Understand that I'm guessing here:
My guess is that digital audio samples always represent a value between -1 and 1 (or perhaps 0 and 1), inclusive. That means that integer samples are just scaled from their "native" range to the integer datatype's range (e.g. 0,1 is scaled to 0,255 for 8-bit samples) for storage. Of course, that means that in order to get the sample's 'intensity', you have to take the source scale into account. And since 16-bit audio in a 24-bit container only uses the range 0,(pow(2, 16)-1) and pad the remaining 8 bits at the end with zeroes. So, purely theoretically, and only if that guess of mine is somewhat correct, the true 24-bit samples should have a (slightly) higher maximum sample 'intensity' value than the 16-bit padded samples, even. By converting everything to 16-bit, though, the maximum 'intensity' value should be the same again.
Anyway, the difference in that example is only that of 16776960 (0xFFFF00) vs 16777215 (0xFFFFFF), which, divided by 16777215 (0xFFFFFF) is approximately 0.999985 and 1.
Again, the above is purely me guessing. I make no claims of correctness, and I didn't even do any research on the topic. It simply seemed to make sense.
In fact, if it's wrong and someone thinks it's better to remove this, I will do so.

gabbett1

11th October 2015, 13:44

just demux it without processing otherwise.

I tried that. It just sits there saying "Please wait.... analyzing selected streams..." and never moves forward.

Thunderbolt8

11th October 2015, 13:52

I tried that. It just sits there saying it's processing and never moves forward.try this then: http://forum.doom9.org/newreply.php?do=newreply&p=1742199

remux the .m2ts file witj tsmuxer before trying to demux or anyhow process the atmos stream.

ndjamena

11th October 2015, 14:00

This is the output from my program for season 2 episode 1:

F:\Videos\Animated Series\The Legend Of Korra\The Legend Of Korra - 2x01 - Rebel Spirit.wav
1235589188: 00:23:50.079999999 - 1235589725: 00:23:50.080621527
1236434846: 00:23:51.058770833 - 1236435383: 00:23:51.059392361

Basically there's a section of about 500 bytes right at the end of the episode that uses the extra 8 bits, and then there's another one.

That would correspond to the "Ginormous Madman" logo and the "NICKELODEON" logo.

That's just stupid. If I'd let the 16 bit down sample happen automatically I'd have lost 5 bits of precision just because of those damn logos at the end. I should probably just leave them the way they are, but calling it 24 bit is a lie. I need to figure out how to get rid of the 24 bit parts automatically, even though it's just 25 episodes it'll still be a PITA to pull off by hand.

I'd need to be able to cut the audio from a "silent" section, just to make sure I don't screw everything up. So I need to start logging silence as well.

Thunderbolt8

11th October 2015, 14:40

cant you just batch edit/delay/cut the logos with eac3to? would that add 16-bit audio delay or 24-bit for a DTS-HD MA track?

ndjamena

11th October 2015, 14:57

Yes, but I'd have to identify them properly first. The first episode of season 1 seems to start with 24 bit at the beginning of the end credits, but the last episode of the season starts at the logos.

This is the output for Pacific Rim:

F:\Make\Movies\ZZZ\Pacific Rim.wav
68: 00:00:00.000000000 - 8363: 00:00:00.009600694

Pacific Rim has 16 bit sound. It's from 2013... it's a 3D IMAX American Blockbuster science fiction film... and it has 16 bit sound. A little over 8000 bytes in the first 10 milliseconds is it's only claim to 24ness. I'm pretty sure I can just use the -dontDither switch on that, unless someone can think of a good reason why that silent blip is there...?

Now I'm going to have to go back and make sure the movies I've already processed hadn't been inflicted with this kind of crap.

buffyangel108

11th October 2015, 15:51

You can use the flac.exe encoder to put any parameter. For instance:

eac3to input stdout.wav | flac -o outfile.flac --ignore-chunk-sizes -0 -

Works a treat, thank you so much!

ndjamena

11th October 2015, 16:22

OK, conundrum:

Terminator Salvation, Extended Edition.

All the movie files are 24 bit DTS-MA with a real bitdepth of 16 bits, except for the very first one which is 16 bit with about 8000 bytes of 24 bit junk at the very beginning. All the "extended edition" m2ts file are actual 16 DTS-MA streams.

Since the first file is "pretend" 24 bit eac3to won't detect it as being 16 bit, but everything after that IS 16 bit. Since it doesn't realise what it's looking at is 16 bit, it's resampling all the 16 bit m2ts files to 24 bit so once the conversion is done there ARE 24 bit segments in there. But I have to extract the audio with either EAC3To or MakeMKV in order to remove the overlaps, but they BOTH resample the 16 bit to 24 bit which makes recovering the 16 bit almost impossible.

When I extract audio from an m2ts to WAV does EAC3To cut it so it's length matches the video stream?

Is there anything better I can do than extract MINUS the first file, process the first file separately and then append the two segments?