eac3to - audio conversion tool [Archive] - Page 14

r0lZ

11th March 2015, 11:30

The bug #86 with the inversion of the left and right eye views when displaying the content of a 3D playlist with the MVC_Base_view_R_flag true is partially fixed.

When eac3to is launched with the BD path as the argument, or with the playlist, it works fine:

C:\>eac3to.exe Y:\BDMV\PLAYLIST\00852.mpls
1) 00852.mpls, 00001.m2ts, 1:34:02
- Chapters, 20 chapters
- h264/AVC (right eye), 1080p24 /1.001 (16:9)
- h264/MVC (left eye), 1080p24 /1.001 (16:9)
- DTS Master Audio, English, multi-channel, 48kHz
- DTS, French, multi-channel, 48kHz
- AC3, Spanish, multi-channel, 48kHz
- AC3, Portuguese, multi-channel, 48kHz
- AC3, Danish, multi-channel, 48kHz
- AC3, Finnish, multi-channel, 48kHz
- AC3, Norwegian, multi-channel, 48kHz
- DTS, Russian, multi-channel, 48kHz
- AC3, Swedish, multi-channel, 48kHz
- AC3, Chinese, multi-channel, 48kHz
- DTS, Japanese, multi-channel, 48kHz

But when the 1) argument is added to display the full content of the playlist, the left and right views are still inverted:

C:\>eac3to.exe Y:\BDMV\PLAYLIST\00852.mpls 1)
M2TS, 2 video tracks, 11 audio tracks, 12 subtitle tracks, 1:34:02, 24p /1.001
1: Chapters, 20 chapters
2: h264/AVC (left eye), 1080p24 /1.001 (16:9)
3: h264/MVC (right eye), 1080p24 /1.001 (16:9)
4: DTS Master Audio, English, 7.1 (strange setup) channels, 16 bits, 48kHz, -9ms
(core: DTS-ES, 5.1 channels, 1509kbps, 48kHz)
5: DTS, French, 5.1 channels, 768kbps, 48kHz, -9ms
6: AC3, Spanish, 5.1 channels, 448kbps, 48kHz, dialnorm: -27dB, -9ms
7: AC3, Portuguese, 5.1 channels, 448kbps, 48kHz, dialnorm: -27dB, -9ms
8: AC3, Danish, 5.1 channels, 448kbps, 48kHz, dialnorm: -27dB, -9ms
9: AC3, Finnish, 5.1 channels, 448kbps, 48kHz, dialnorm: -27dB, -9ms
10: AC3, Norwegian, 5.1 channels, 448kbps, 48kHz, dialnorm: -27dB, -9ms
11: DTS, Russian, 5.1 channels, 768kbps, 48kHz, -9ms
12: AC3, Swedish, 5.1 channels, 448kbps, 48kHz, dialnorm: -27dB, -9ms
13: AC3, Chinese, 5.1 channels, 448kbps, 48kHz, dialnorm: -27dB, -9ms
14: DTS, Japanese, 5.1 channels, 768kbps, 48kHz, -9ms
15: Subtitle (PGS), English
16: Subtitle (PGS), French
17: Subtitle (PGS), Spanish
18: Subtitle (PGS), Portuguese
19: Subtitle (PGS), Danish
20: Subtitle (PGS), Finnish
21: Subtitle (PGS), Norwegian
22: Subtitle (PGS), Russian
23: Subtitle (PGS), Swedish
24: Subtitle (PGS), Chinese
25: Subtitle (PGS), Japanese
26: Subtitle (PGS), Japanese

(This is the Ice Age 3 3D Panasonic Bundle. I haven't tested with the 2 other 3DBDs I have with the inverted views, but I guess they give the same result.)

madshi

11th March 2015, 11:37

I'll need a sample. One which is complete enough so I can fully reproduce the incorrect listing.

tebasuna51

11th March 2015, 11:50

eac3to v3.28 released
Thanks madshi!

Also please make sure TrueHD decoding still works losslessly, as usual (even for non-Atmos tracks).
I'll make some test and report.

* downStereo: added 0.7071 factor for surround/back channels (ITU-R BS.775-3)
No problem for me, that enhance a little the front channels info (more important) over the surround channels.

* downStereo/Dpl: using 0.5 instead of 0.7071 factor for LFE (ITU-R BS.775-3)
I can't se this recomendation in ITU-R BS.775-3, I only read than LFE don't be used at all in downmix.

@all users
Please read ITU-R BS.775-3 (http://www.itu.int/rec/R-REC-BS.775-3-201208-I/ee) to understand for what add LFE is not recommended for downmix.
Use -mixlfe at your risk.

Sparktank

11th March 2015, 11:59

eac3to v3.28 released

Excellent update!

@all users
Please read ITU-R BS.775-3 (http://www.itu.int/rec/R-REC-BS.775-3-201208-I/ee) to understand for what add LFE is not recommended for downmix.
Use -mixlfe at your risk.

noted and PDF downloaded.

madshi

11th March 2015, 12:05

Thanks madshi!
Pleasure! It was about time... :o

I'll make some test and report.
Thanks, appreciated!

No problem for me, that enhance a little the front channels info (more important) over the surround channels.

I can't se this recomendation in ITU-R BS.775-3, I only read than LFE don't be used at all in downmix.
That's true. My thinking was like this:

Originally I mixed left, right and surround channels with 1.0, and the LFE with 0.7071. The reason for using 0.7071 for LFE was because it was originally only one channel/speaker, but I've mixed it into both the final left *and* right channels. So I had to half the volume of the LFE to not increase its final playback volume.

Now ITU 775-3 suggests to use 1.0 for left/right channel, but 0.7071 for the surround channels. The ITU idea is that the left/right channels should have higher priority than the surround channels. If we accept this idea, it should also be applied to the subwoofer. Why would we lower the surround channel volume for the mix, but not the LFE volume? Because of that I've used the original matrix, but added an 0.7071 factor on all channels (including LFE) except left/right. This is how I ended up with 0.7071 for the surround channels and 0.5 for the LFE.

ITU 775-3 does suggest not to mix the LFE at all, and IIRC that's eac3to's default behaviour, anyway. But *if* the user wants to mix the LFE, the volume should make sense, and since I just lowered the surround volume, I thought it would make sense to lower the LFE volume (when -mixlfe is used), accordingly.

r0lZ

11th March 2015, 12:14

I'll need a sample. One which is complete enough so I can fully reproduce the incorrect listing.
OK, I'll try to find a 3D short that can serve as an example. Currently, I can't do much better than the sample I gave you. I don't know how to cut the SSIF and the two M2TS files at the right position.

madshi

11th March 2015, 12:19

I don't think it has to be the "right" position. It just has to be big enough to allow eac3to to detect the video track properties. Probably something like 50MB for the first SSIF and 25MB for the first m2ts file would work ok. If the playlist contains multiple m2ts files, and the first one is smaller than 50MB, leave the first m2ts/ssif file untouched and shorten the 2nd one so that the overall sum is 25MB/50MB. Something like that. You can always test this right away on your PC: If eac3to reproduces the problem with your cut down sample, then you've done well and you can zip/upload it.

r0lZ

11th March 2015, 12:32

Stereodude

11th March 2015, 12:55

There is something to extract, for example the latest version of mkvmerge can get the embedded AC3 track for you.
Please explain to me how a tool can extract something that isn't there. THD has no core. THD is packed with an AC3 track on Blu-ray because the specs require it and some people call that the "core", but THD doesn't have a core. THD can be separated from the "core" (the ac3 packed with it) and still be decoded. For example, HD-DVD had THD with no AC3 track packed along side of it.

madshi

11th March 2015, 13:05

OK. But I don't understand why you need the video files. The flag is in the MPLS file only, and it should be sufficient to read it to know that the 2 views are inverted. Anyway, I am preparing a sample...
The reason is that there's a difference between implementing something with or without the ability to test it. I tried to implement it without being able to test it, and as you reported, my implementation only half worked. I don't know why it doesn't fully work, I thought it would. That's why I need the sample, so I can analyze better why it fails to work completely. If you're a dev you should know that it's important to be able to test something, instead of just implementing something "blindly". If you're not a dev, then that's ok, you probably couldn't know... :p

r0lZ

11th March 2015, 13:23

I'm a dev, and I know that if I get the right flag, it is easy to simply swap the left and right strings in the output. But I understand your point.

I did 3 samples, but none are perfect. When I cut 50MB of the SSIF and respectively 30 and 20 MB of the AVC and MVC M2TS files, eac3to can list the streams when using the "1)" argument (with the full parsing of the video file), but it lists only the chapters when used without the "1)" argument. I don't understand why, so I have made a new sample with file sizes twice as big. Same result!

My third test is completely different: I have taken a short menu file (one minute long) with the standard left/right order of the views, and I have patched the MPLS with an hex editor to set the base view R flag. IMO, my patch should be sufficient to invert the views, but I don't know if there are other differences regarding the left/right views order. Now, eac3to works exactly as described in my post above: correct without the "1)", but wrong with it. It lists all streams in both cases (without the subpics in the first case, but it's normal.) The total size of that sample is 621MB. A bit too much, but I should be able to post it somewhere. Unfortunately, I don't have any 3D clip with the views inverted short enough to be uploaded somewhere, so I had to use that trick.

Do you want the first sample, that doesn't show the video streams without the 1) argument, or the second one, fully working but big and not "official"?

Boulder

11th March 2015, 13:30

Please explain to me how a tool can extract something that isn't there. THD has no core. THD is packed with an AC3 track on Blu-ray because the specs require it and some people call that the "core", but THD doesn't have a core. THD can be separated from the "core" (the ac3 packed with it) and still be decoded. For example, HD-DVD had THD with no AC3 track packed along side of it.I don't know, you would have to ask Mosu about it.

2015-02-10 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: mkvmerge will now recognize TrueHD+AC3 files as consisting of two tracks. Instead of always dropping the AC3 part the user can simply select which tracks to keep. Part of the implementation of #1107.

r0lZ

11th March 2015, 13:38

When I cut 50MB of the SSIF and respectively 30 and 20 MB of the AVC and MVC M2TS files, eac3to can list the streams when using the "1)" argument (with the full parsing of the video file), but it lists only the chapters when used without the "1)" argument.
Sorry, I didn't know that it is necessary to include the CLIPINF directory as well. I have added it in the first sample, and now eac3to can lists the streams even without the 1) argument. I will upload that sample...

[EDIT] Sample uploaded. See the bug tracker for the link.

szabi

11th March 2015, 14:12

With TSmuxer, check "downconvert True HD ..." in track options and choose demux as output format. Don't worry, that's an extraction, not a conversion (encoding).

I tried, but did not worked.

Q-the-STORM

11th March 2015, 14:41

thanks madshi for the new version... I hope you have a bit more time in the future and replace aften with libav/ffmpeg for ac3 encoding :P

I don't know, you would have to ask Mosu about it.

alright..

on the BD there is a TrueHD track with an embedded AC3 track...
those 2 tracks can both work completely independently... you can "extract" the AC3 track and it will work without TrueHD and you can "extract" the TrueHD Track and it will work without the AC3 Track....

the AC3 Track is embedded for backward compatibility with receivers WITHOUT having to change to another audio track...
so people can bitstream it and if the receiver can't decode TrueHD, it can fall back on AC3....

BUT the big difference to DTS is, that DTS-HD will not work without the DTS core... that's why on DTS it's called a core and on TrueHD it's called embedded... on DTS-HD you can extract the core, but you can't have DTS-HD wihtout the core... DTS-HD is simply the Core + extra information to make it lossless (on DTS-HD MA at least)...

TrueHD is lossless all on it's own, it doesn't need the AC3 track at all.

so in eac3to you have the option to demux thd, ac3 or thd+ac3...
all of those options will give you one file...

and here's the thing:
the m2ts (Blu-ray) container supports embedded tracks, the matroska container doesn't!
so if you want to have a TrueHD track in mkv, you HAVE TO remove the embedded track!

in the past, mkvmerge did exactly this... They just removed the embedded AC3 track and muxed the TrueHD track only.
but there are people that want the AC3 track as well, they would have to extract the embedded AC3 track with eac3to or tsmuxer or any other tool seperately and then mux it.

Now mkvmerge eliminated this step. Instead of simply removing the embedded AC3 track, it gives the option to mux it in as a SEPERATE audio track. if you now bitstream the TrueHD track, your receiver does not have to option to fall back on AC3 anymore, you have to select the seperate ac3 track in your player...

now if you have a mkv file with a trueHD track, or you have extracted the TrueHD track with eac3to (and didn't use thd+ac3 extension) then there is no embedded AC3 Track anymore. If you want to get an AC3 track from it, it HAS to be encoded...

Snowknight26

11th March 2015, 14:41

Ooops, too late. Why didn't you create a bug tracker entry for this, then I might have looked at it. Now 3.28 is already done.

Anyway, are you sure that the real playlist and the one selected by eac3to are really different? Often there are multiple duplicates, and eac3to simply selects one "by random".

Aside from the different chapters they're identical.

Thanks for the new version regardless!

madshi

11th March 2015, 15:38

I'm a dev, and I know that if I get the right flag, it is easy to simply swap the left and right strings in the output.
Well, it's not as easy as it sounds, because when doing "1)" eac3to goes a totally different way. It analyzes the m2ts files and mostly disregards the mpls information. Only later the m2ts parsing results and the mpls information is tried to be tied together again. This is a quite complicated process (eac3to even tries to automatically find a matching playlist even if you manually entered a number of m2ts files instead of the mpls), and that's why it's not that easy to implement this without being able to test it.

Aside from the different chapters they're identical.
Oh. It's possible that eac3to isn't comparing the chapters when deleting "duplicate" playlists from the listing.

Stereodude

11th March 2015, 16:35

I tried, but did not worked.
That's because your TrueHD has no embedded AC3 track to extract. No tool can extract what isn't there. You can only extract AC3 from TrueHD+AC3 tracks.

tebasuna51

11th March 2015, 18:46

- Test decoding 5 standard TrueHD samples with different number of channels, bitdepth and samplerate:
the eac3to v3.27 and v3.28 output are bit-identical.

- Test decoding 3 TrueHD Atmos samples (I don't have many samples):
the eac3to v3.28 output and a recent ffmpeg are bit-identical.

- Test over 2 TrueHD Atmos samples extracting the AC3 core:
the eac3to v3.28 output is better than tsMuxeR extraction because tsMuxeR add extra garbage at end of the AC3.

madshi

11th March 2015, 18:50

Thanks for the tests!

jpsdr

11th March 2015, 23:51

Have you bothered to read the announcement post? Read the last sentence again.

You're absolutely right, i'm stupid i didn't see it, all my sincere appologies !

Thanks for your work.

Overdrive80

12th March 2015, 01:07

Hi, thanks for updated. For any reason, I never get update haali version according to eac3to (I install last version from http://haali.su/mkv/):

"Haali Matroska Muxer (2013-04-14) is installed
There's a new version (2013-06-23) available
http://haali.net/mkv"

Thanks
Any fix or workaround?

Sparktank

12th March 2015, 02:02

"Haali Matroska Muxer (2013-04-14) is installed
There's a new version (2013-06-23) available

IIRC, they're the same code.
The 4-14 was the beta version that was tested before releasing it as official (06-23).
The date is the only thing truly different as everything else remained identical in the official release.
For some reason the Haali site never really updated because I downloaded their binary and never got the 06-23 date to silence eac3to.

I use K-Lite Codec Pack, and they've since updated to the binary with the most recent date, just to please eac3to users.
Or OCD users.

I went weeks, maybe months before I even noticed KLCP updated the cosmetic date.

Somone might have a link to a binary with the date eac3to expects.
Or whatever codec pack you're using (if any), you could ask them to update their installer.

mariner

12th March 2015, 04:53

eac3to v3.28 released

http://madshi.net/eac3to.zip

* fixed: #001: different number of frames for left and right eye
* fixed: #061: valid silence edit was sometimes rejected
* fixed: #067: error messages were not available to GUIs
* fixed: #086: left/right eye information was inverted in some 3D Blu-Rays
* fixed: #131: TrueHD Atmos streams could not be demuxed or decoded
* fixed: #243: ArcSoft DTS decoder crash made eac3to crash, too
* downStereo: added 0.7071 factor for surround/back channels (ITU-R BS.775-3)
* downStereo/Dpl: using 0.5 instead of 0.7071 factor for LFE (ITU-R BS.775-3)
Please note that some of these changes have been implemented without a lot of testing. So it would be great if you guys could double check things, especially the changes, to make sure they really work as intended. Also please make sure TrueHD decoding still works losslessly, as usual (even for non-Atmos tracks). I've hacked Atmos "support" into the old ffmpeg version I've been using for years, so I wouldn't have to update to the latest ffmpeg version. Don't have much time atm, so I tried to do the most important stuff with the least amount of work.

Greetings madshi. Many thanks for the update.

howzz

12th March 2015, 08:48

in the process of trying to find ways to speedup the demuxing, muxing process, i came across one of the change logs that was mentioned here. i think it was version 2+ "improvement of the speed performance of the muxing process", or something that nature.

i am a long time user of Ripbot264. recently i moved my working folder from a secondary HDD to a primary SSD and noticed the initial demuxing process in ripbot went from 23 mins to 11 mins. i was looking for more ways to improve the speed of the demux and realized by moving to an even faster SSD made no difference. it got me thinking whether the DDR3 RAM speed is the factor, or is it the software ie. hali/eac3to etc..

According to Resource Monitor, the eac3to process (during ripbot264 demuxing), is only reading at 50~60MB/s and writing the video.mkv stream at about the same speed. And by moving to an even faster SSD, the SSD utilization does not go up, in fact, it's well under 100%. CPU utilization is less than 5% so it's not really fully utilizing the full potential of the SSD, or the CPU. the only other hardware i can think of would be the RAM. but before i go out and upgrade from DDR3 1866 to DDR3 2600, i just want to make sure that it's not the software.

could someone shed some light on this subject? is it Hali's fault? or is it a hardware limiting factor? my rig is i7 @4.8ghz with Crucial SSD M4 and Crucial MX100, DDR3 1866 16GB. what can i do to farther improve the demuxing speed.

thanks so much!

tebasuna51

12th March 2015, 09:23

... and noticed the initial demuxing process in ripbot went from 23 mins to 11 mins.

:logfile:
and we can say you how know the culprit.

Nebudchanezzer

12th March 2015, 15:23

Atak_Snajpera

12th March 2015, 18:35

howzz

12th March 2015, 18:49

Reading / writing to the same SSD?

Might be SATA that is the bottleneck.

Test with reading from one ssd and writing to another.

i did several tests last night.

one single SSD (7mins:10sec) vs HDD to SSD (7mins:38sec) vs HDD only (23mins:38sec). the source was Casino Royal AVC Blu-ray ISO decrypted from AnydvdHD.

the results were interesting, especially when you factor in MPEG2 source vs AVC source.

with MPEG2, source Alient VS Predator (ISO)
one single SSD (9mins:4sec) vs HDD to SDD (11mins) VS HDD (i didn't bother)

since i only have one SSD on the main machine, which is ICH10 SATA 600. i couldn't test SSD to SSD.

i really don't think it's the SATA bottle-necking, since resource monitor only shows reading from the source at roughly 65MB/s, and writing to the Video.mkv at roughly 55MB, and Audio at about 5~10MB. the thing is, Ripbot or is it EAC3, demux video, audio, and sub all at the same time. would it be faster if the demux process is programmed in series instead of parallel? i am not a programmer, but i am just asking.

howzz

12th March 2015, 18:54

I wonder how big chunks of data does eac3to use during remuxing? Some time ago I had written small benchmark for SSD which test read and copy speed in unbuffered mode.
http://forum.pclab.pl/topic/974463-File-Transfer-Speed-Test/

Here are results for copy speed (Y-axis speed in MiB, X-axis file size in KiB)
http://i.cubeupload.com/IRCQsP.png

As you can see speed is not very good for small chunks of data.

Thanks Atak,

nice to see the maker of Ripbot in here.

this is very interesting data. i wonder how small are the chunks that eac3to is dealing with. are they 4K sizes, 1024? etc. because if they're as small as 4K, i might experiment going out and buy the fastest 4K SSD that's out there. but then again, somehow i have doubts that's the culprit.

is it because the way eac3to reads the source?

one thing was interesting last night was if i let DVDFab do the decryption and demux, instead of AnyDVD. DVDFab spits out the demuxed MKV, which contains original video, audio and sub (all passthrough), Ripbot doesn't demux the video.mkv again, it just uses the video straight, and demuxes the audio only, which only takes a 1 minute.

then again, i am always wary about DVDFab, and the way that program runs, which tends to favor speed over quality.

howzz

12th March 2015, 18:56

:logfile:
and we can say you how know the culprit.

which log do you want me to post, and where would i go to get to the log file.

madshi

12th March 2015, 19:11

howzz

12th March 2015, 20:10

eac3to reads 1MB chunks if the source file is any sort of container (e.g. MKV, m2ts or EVO), and it reads 256KB chunks if the source file is anything else (e.g. a separate audio or video track). Writes are done in 1MB chunks. I guess I could increase the read chunk sizes. However, increasing the write chunk sizes is kinda dangerous, because doing so would require me to have a cache in the size of the chunk size of every potential output track. Some Blu-Rays have dozens and dozens of audio and subtitle tracks. Imagine 100 tracks with a chunk size of 16MB. That would already bring us to 1.6GB, and a win32 process is only allowed to allocate 2GB. So increasing the output chunk size can quickly result in out-of-memory situations, if I'm not careful.

There are various possible reasons for slowdown. Of course it's quite possible that some processing filters in eac3to are wasting time. Or it's possible some external software is wasting time (e.g. Haali MKV muxer). Or it's possible that the SSD or the OS is at fault. It's really hard for me to say. A couple tests you could do:

1) Try "eac3to source -check". That will just read the source and demux it, but not encode or write anything.
2) If 1) already shows slow speeds, try a simply "copy" command line command to check how fast that runs through.
3) If 1) already shows slow speeds, try different containers to see if the problem might be specific to one (or several) containers.

thanks Madshi, for the informative response. this really gives a lot of insights into the inner workings.

i'll run some tests when i get home tonight.

can i just say that i support upping the read chunk size. :thanks: at the very least if not the write chunk.

also, i am not sure how many are still running on x86 32bit os, but would it be a possibility to perhaps release a 64bit eac3to that allocates more write cache to get around the 2GB memory allocation issue.

i tend to think that folks who are smart enough to come across eac3to, most likely are running minimum 8GB of ram and 64bit OS. but that's just my guess.

thanks!

Atak_Snajpera

12th March 2015, 21:02

73ChargerFan

12th March 2015, 21:04

Thanks madshi for the update.

I have a question regarding Atmos support. Will eac3to save a THD/Atmos stream as THD without Atmos? Or perhaps the extended Atmos data cannot be removed.

Overdrive80

12th March 2015, 21:29

Somone might have a link to a binary with the date eac3to expects.
Or whatever codec pack you're using (if any), you could ask them to update their installer.

Thanks for you answer, i use cccp códecs, i gonna try klcp. (Really is not importante but eac3to in this sense show message wrong)

howzz

12th March 2015, 22:41

I think that 1MiB for read is ok. The problem is most likely in write size. However some cheaper SSDs still need larger size for max speed. Personally I own C100 so I wouldn't mind if read size was increased up to 16 MiB - 64 MiB for max performance.

it's good to see the maker of ripbot actively involved in eac3to. hopefully in the future release of ripbot, we'll see a faster version of eac3to, and waiting for demuxing will be the thing of the past, that's my dream.

:thanks:

Groucho2004

12th March 2015, 23:17

Personally I own C100 so I wouldn't mind if read size was increased up to 16 MiB - 64 MiB for max performance.
That's ridiculous and you obviously didn't read madshi's post about write block sizes.

Atak_Snajpera

12th March 2015, 23:38

That's ridiculous and you obviously didn't read madshi's post about write block sizes.

Read my post again.
I wrote 16 MiB - 64 MiB for read chunk not for write chunk. I understand that memory issue is only for write.

Personally I do not mind 16 MiB for read and write. Madshi could limit this value if bluray movie has insane number of streams. Also I don't see problem if eac3to will temporary eat 2 GiB of my ram. Most decent pcs have atleast 4GiB.

howzz

13th March 2015, 00:03

i wonder how much ram it would consume if the read/write chunk were optimized to 16M/16M. if Atak's benchmark is any consolation, even 16MB will pretty much provide the majority of performance increase.

i am sure 2GB of working allocated memory shouldn't be anything anyone should worry about. only person i know in my life that's still using 4GB memory is my mother in law, and she doesn't know what eac3to is. even then, she's on a 64bit win7.

anything Madshi can do would be greatly appreciated. :)

Atak_Snajpera

13th March 2015, 00:12

Like Madshi said It depends how many streams (VIDEO,AUDIO,SUBTITLES) you have in container.

Groucho2004

13th March 2015, 00:28

i am sure 2GB of working allocated memory shouldn't be anything anyone should worry about.
You're ignoring the fact that eac3to is a 32 Bit application which limits the user address space to 2G (4G with some tweaking on a 64 Bit OS).

Groucho2004

13th March 2015, 00:45

Read my post again.
I wrote 16 MiB - 64 MiB for read chunk not for write chunk. I understand that memory issue is only for write.

Personally I do not mind 16 MiB for read and write. Madshi could limit this value if bluray movie has insane number of streams. Also I don't see problem if eac3to will temporary eat 2 GiB of my ram. Most decent pcs have atleast 4GiB.
Have a look at the ATTO ssd benchmarks, for example on Anandtech. Most ssd's max out at 64 K block size, read or write.

I don't know how you wrote your benchmark but copying files with a size of e.g. 1MB 100 times is not the same as copying a file of 100 MB with 1 MB block size.

arrgh

13th March 2015, 00:57

Oh. It's possible that eac3to isn't comparing the chapters when deleting "duplicate" playlists from the listing.

is there an Option to suppress the deletion of "duplicate" playlists? In times of "playlist obsfucation / screen pass" that might be a useful Option...

Atak_Snajpera

13th March 2015, 12:40

Have a look at the ATTO ssd benchmarks, for example on Anandtech. Most ssd's max out at 64 K block size, read or write.

I don't know how you wrote your benchmark but copying files with a size of e.g. 1MB 100 times is not the same as copying a file of 100 MB with 1 MB block size.

1. atto by default works with compresible data
This allows sandforce controller to cheat.

2. atto is using by default queue depth=4
The most common depth in real tasks is queue = 1.

Atak_Snajpera

13th March 2015, 12:46

My bench works in queue 1.

Copying is done by simple windows function CopyFileEX with COPY_FILE_NO_BUFFERING flag. (https://msdn.microsoft.com/en-us/library/windows/desktop/aa363852%28v=vs.85%29.aspx)

If think that eac3to also works in queue 1 hence big size of data is needed to saturate all channels in SSD's controller.

Q-the-STORM

13th March 2015, 15:05

Imagine 100 tracks with a chunk size of 16MB. That would already bring us to 1.6GB, and a win32 process is only allowed to allocate 2GB. So increasing the output chunk size can quickly result in out-of-memory situations, if I'm not careful.

couldn't you simply give the user the option to use a smaller chunk size? 16MB as default, and flags -1MB -2MB -4MB -8MB for smaller sizes...
or is implementing different chunk sizes a lot of work? 16MB default and an optional -1MB flag would probably do just as well then... or 16 default and 8MB, I don't think there will be many sources with more than 200 tracks... you could also just let eac3to decide, if a source has more than 100 tracks -> use 8MB, more than 200 tracks -> use 4MB...
though I do think 16MB default and flags to let the user decide would be the best thing, especially for people that use most of their RAM in normal use and don't always want or aren't able to spare more for eac3to..

anyways, most times you got 3-20 tracks, so 16MB default would almost always be a good thing...

r0lZ

14th March 2015, 11:31

The buffer size could also be computed at run time, according to the number of streams and available free RAM. IMO, it's the best option, and it should ideally be available if the idea of an option with several buffer sizes is implemented, as an additional "auto" size.

Lenmaer

14th March 2015, 11:44

This an SSD benchmark thread now?

madshi

14th March 2015, 11:46

is there an Option to suppress the deletion of "duplicate" playlists? In times of "playlist obsfucation / screen pass" that might be a useful Option...
eac3to only drops duplicate playlists. That should actually help with obfuscation because the insane number of playlists is reduced a bit by this.

-------

About eac3to performance: It's a bit unfortunate that everybody is talking about chunk sizes now, without looking at anything else. I don't think the chunk size is the problem, nor the key to salvation. As I wrote earlier:

There are various possible reasons for slowdown. Of course it's quite possible that some processing filters in eac3to are wasting time. Or it's possible some external software is wasting time (e.g. Haali MKV muxer). Or it's possible that the SSD or the OS is at fault. It's really hard for me to say. A couple tests you could do:

1) Try "eac3to source -check". That will just read the source and demux it, but not encode or write anything.
2) If 1) already shows slow speeds, try a simply "copy" command line command to check how fast that runs through.
3) If 1) already shows slow speeds, try different containers to see if the problem might be specific to one (or several) containers.
I've tried to increase chunk sizes here on my Samsung Pro SSD, and it didn't help performance *at all*. Same performance as before. The problem is likely to be somewhere else. One suspicion I have is that eac3to's parsing of the video track might be at fault - especially when h264 is involved. eac3to fully parses every bit of every video track, and for h264 even rewrites the stream every time, "bit by bit". This *may* be the decisive slow down factor. Or maybe not. I hope that now not everyone will talk about how to fix h264 slowdown problems in eac3to. I'm just throwing around some thoughts here. None of this is tested or proven. I don't have a lot of time atm, anyway, so if the real cause of the problem is more complex than the chunk size (which I think it probably is), I won't have time to fix that soon. But instead of discussing things I could do, please guys, first try to find out by doing analytical tests where the real bottleneck is.

Atak_Snajpera

14th March 2015, 18:21

1) Try "eac3to source -check". That will just read the source and demux it, but not encode or write anything.
2) If 1) already shows slow speeds, try a simply "copy" command line command to check how fast that runs through.
3) If 1) already shows slow speeds, try different containers to see if the problem might be specific to one (or several) containers.

AVC.mkv
General
Unique ID : 245455972442929439196667259541358469211 (0xB8A919C9CFCD744DB899E6E03D99605B)
Complete name : C:\Users\Dave\Desktop\Drive-AVC-remux.mkv
Format : Matroska
Format version : Version 4 / Version 2
File size : 2.44 GiB
Duration : 10mn 15s
Overall bit rate mode : Variable
Overall bit rate : 34.0 Mbps
Encoded date : UTC 2015-03-14 16:43:32
Writing application : mkvmerge v7.2.0 ('On Every Street') 32bit built on Sep 13 2014 15:42:11
Writing library : libebml v1.3.0 + libmatroska v1.4.1
DURATION : 00:10:15.031000000
NUMBER_OF_FRAMES : 14746
NUMBER_OF_BYTES : 2617507214
_STATISTICS_WRITING_APP : mkvmerge v7.2.0 ('On Every Street') 32bit built on Sep 13 2014 15:42:11
_STATISTICS_WRITING_DATE_UTC : 2015-03-14 16:43:32
_STATISTICS_TAGS : BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 10mn 15s
Bit rate mode : Variable
Bit rate : 33.4 Mbps
Maximum bit rate : 37.0 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.671
Stream size : 2.39 GiB (98%)
Default : Yes
Forced : No

VC-1.mkv
General
Unique ID : 178944820121177913025717090745631236997 (0x869F84CC91034C4D9ED0E1E12775E385)
Complete name : C:\Users\Dave\Desktop\Last_Man_Standing_VC1_10Min-remux.mkv
Format : Matroska
Format version : Version 4 / Version 2
File size : 1.70 GiB
Duration : 10mn 0s
Overall bit rate : 24.3 Mbps
Encoded date : UTC 2015-03-14 16:33:38
Writing application : mkvmerge v7.2.0 ('On Every Street') 32bit built on Sep 13 2014 15:42:11
Writing library : Lavf52.110.0

Video
ID : 1
Format : VC-1
Format profile : Advanced@L3
Codec ID : V_MS/VFW/FOURCC / WVC1
Codec ID/Hint : Microsoft
Duration : 10mn 0s
Bit rate : 23.8 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.479
Stream size : 1.66 GiB (98%)
Default : Yes
Forced : No
DURATION : 00:10:00.058000000
NUMBER_OF_FRAMES : 14387
NUMBER_OF_BYTES : 1822959885
_STATISTICS_WRITING_APP : mkvmerge v7.2.0 ('On Every Street') 32bit built on Sep 13 2014 15:42:11
_STATISTICS_WRITING_DATE_UTC : 2015-03-14 16:33:38
_STATISTICS_TAGS : BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES

eac3to -check

http://i.cubeupload.com/qrgGIz.png

madshi

14th March 2015, 18:28

Ok, thanks, and maybe something without any video tracks?

Atak_Snajpera

14th March 2015, 18:33

What do you mean? Audio only?

trevaaar

16th March 2015, 16:25

I have a file that eac3to erroneously detects as being HDCD-encoded. It's a 24-bit 5.1-channel FLAC (though most samples are zero-padded 16-bit). The problem with this is that HDCD decoding appears to be force-enabled when converting to a lossy format, so attempts to transcode to AC3 always fail with the error "there is no HDCD data to decode" regardless of whether I pass in -decodeHdcd or not.

First few seconds of the file that exhibits the problem: https://mega.co.nz/#!59kX0ASb!MwwBiFhAQCy8EvCOTuifDxXEFJoSHMSAiEs26I1rBHk

madshi

16th March 2015, 19:22

What do you mean? Audio only?
Yes, some file with a similar file length (e.g. some DTS-HD or TrueHD track muxed to MKV or so) without a video track. Just to check if video stream parsing might be responsible for the slowdown.

I have a file that eac3to erroneously detects as being HDCD-encoded. It's a 24-bit 5.1-channel FLAC (though most samples are zero-padded 16-bit). The problem with this is that HDCD decoding appears to be force-enabled when converting to a lossy format, so attempts to transcode to AC3 always fail with the error "there is no HDCD data to decode" regardless of whether I pass in -decodeHdcd or not.

First few seconds of the file that exhibits the problem: https://mega.co.nz/#!59kX0ASb!MwwBiFhAQCy8EvCOTuifDxXEFJoSHMSAiEs26I1rBHk
http://eac3to.bugs.madshi.net

Thunderbolt8

17th March 2015, 21:15

what to think of this? http://forum.timramich.com/viewtopic.php?f=16&t=26

madshi

17th March 2015, 21:54

tebasuna51

17th March 2015, 22:37

what to think of this? http://forum.timramich.com/viewtopic.php?f=16&t=26

To decode "7.1 - L, R, C, LFE, Ls, Rs, Lsr, Rsr" (strange setup) losslessly, like if was "7.1 - L, R, C, LFE, Lss, Rss, Lsr, Rsr", you can use MakeMKV, the dtsdecoderdll.dll from ArcSoft and a profile like the attached.

nevcairiel

18th March 2015, 00:50

It's known that the DTS encoding suite can decode 7.1 channels losslessly. But that's a copy protected software and not easy to remote control from eac3to. So it's not really a good option for eac3to. There might be an open source decoder available soon, though, which might solve this problem. Or maybe not, we'll have to wait and see...

The good news is that the "strange setup" can already be decoded completely lossless with this potential decoder, well, at least the sample I had.

Its fun to see what other "reference" decoders do with strange-setup though. Somehow they postprocess the channels to make a "normal" surround setup out of them, because they assume any software couldn't possibly comprehend the extra front-surround channels.

madshi

18th March 2015, 01:36

The good news is that the "strange setup" can already be decoded completely lossless with this potential decoder, well, at least the sample I had.
Great! :)

Its fun to see what other "reference" decoders do with strange-setup though. Somehow they postprocess the channels to make a "normal" surround setup out of them, because they assume any software couldn't possibly comprehend the extra front-surround channels.
Yeah. And some ArcSoft versions even produced corrupted sound data... :eek:

Nebudchanezzer

18th March 2015, 09:51

To decode "7.1 - L, R, C, LFE, Ls, Rs, Lsr, Rsr" (strange setup) losslessly, like if was "7.1 - L, R, C, LFE, Lss, Rss, Lsr, Rsr", you can use MakeMKV, the dtsdecoderdll.dll from ArcSoft and a profile like the attached.

Didn't know that, very interesting!

Did a test with a small track I have encoded with MA-suite to both
"normal" setup and "strange setup", seems to work great except there seems to be one extra DTS-frame at the end of the "strange setup"-track.

Don't know if that is something added by the MA-suite or if MakeMKV add an extra though.

Thank you for the info anyway!

Looking forward to the new codec!

EDIT:From Foobar:

Differences found in compared tracks.

Comparing:
"N:\Decode.test.reencoded.to.standard.setup.flac"
"N:\title00_track2_eng_DELAY 0ms.flac"
Length mismatch : 4:18.154667 vs 4:18.165333, 12391424 vs 12391936 samples.
Compared 12391424 samples, discarded last 512 samples from the longer file.
No differences in decoded data found within the compared range.

arrgh

18th March 2015, 22:13

...just a tiny small remark, not really very critical :

for me it is inconvinient that "-progressnumbers" gives a line feed after each number; I would prefer, if the Output would remain in the same line (CR without LF)...

Atak_Snajpera

18th March 2015, 22:48

progressnumber switch was added for gui makers. It is easier to capture output if you have new line.

r0lZ

18th March 2015, 23:15

It is impossible to change the --progressnumbers behaviour. It is used by many GUIs, and even a very small change would break them.
If you want only a single line of output, do not specify the --progressnumbers argument, and watch the progress bar.

madshi

18th March 2015, 23:42

Btw, does the GUI error message capturing work now with the latest eac3to?

r0lZ

18th March 2015, 23:44

Sorry, I haven't tested that yet. I will try tomorrow.

stax76

19th March 2015, 01:05

Btw, does the GUI error message capturing work now with the latest eac3to?

yes :thanks:

r0lZ

19th March 2015, 10:58

Indeed, the error message is now correctly captured when STDERR is redirected. There are still many control characters and spaces that makes it difficult to parse the error message, but that difficulty is less important. However, if you can remove the formatting characters when eac3to detects that the output (STDOUT and/or STDERR) is redirected, or when an option is specified on the command line, I'm sure that will simplify the life of the programmers of the eac3to GUIs. But don't worry. Currently, I have what I need. Thanks for the fix!

madshi

19th March 2015, 12:03

stax76

19th March 2015, 12:09

A good way to handle output it is make a dedicated class and always capture both stderr and stdout simultaneously. If I remember right only eac3to requires to trim (start and end) or to remove certain chars like back char and only DGIndex requires to use regex because it outputs progress too minimalistic. Another interesting thing is that mkvmerge, mkvextract and ffmpeg output UTF8, I guess it's standard for unix tools, in .NET it can be defined using the properties ProcessStartInfo.StandardErrorEncoding and ProcessStartInfo.StandardOutputEncoding. Handling eac3to output is for beginners definitively the most difficult but I suggest to see it as learning experience. :)

edit:

Won't it break current GUIs if I suddenly drop all those control chars from the output?

Mine wouldn't break I think, I don't mind breaking changes as long as I know about it.

my code is still pretty easy:

Using proc As New Proc
proc.Init("Convert to WAV/FLAC using eac3to")
proc.File = Packs.eac3to.GetPath
proc.Arguments = args
proc.TrimChars = {"-"c, " "c}
proc.RemoveChars = {VB6.ChrW(8)} 'backspace
proc.SkipStrings = {"process:", "analyze:"}
proc.AllowedExitCodes = {0, 1}
proc.Start()
End Using

it's a nice example that array literals are a kick ass feature that C# don't has

madshi

19th March 2015, 12:14

Haha! Well, it wasn't my intention to make it difficult. I'm willing to make it easier, so I'm open for suggestions, but I also don't want to break current GUIs.

r0lZ

19th March 2015, 12:19

I'm not sure if/how I can detect whether stdout/stderr are redirected. Those control chars are probably spaces and backspaces etc? Won't it break current GUIs if I suddenly drop all those control chars from the output?
It's a risk. It is probably better to implement a new option such as -gui, to output only plain text.

And yes, the control characters are mainly BS and spaces. I don't think the characters that control the color or bold attributes are included in the redirected output, but I'm not sure.

Anyway, as stax76 wrote, it is difficult but not impossible and a good exercise to parse the current format. Don't worry too much, and implement a modification only if it's easy for you.

Atak_Snajpera

19th March 2015, 15:53

Haha! Well, it wasn't my intention to make it difficult. I'm willing to make it easier, so I'm open for suggestions, but I also don't want to break current GUIs.

If ain't broke don't fix it ;) -progressnumbers works well. No need to waste your precious time for this.

r0lZ

19th March 2015, 16:24

-progressnumbers is perfect as it is and should not be modified. The problem are the other lines printed to STDOUT (and, perhaps, to STDERR). They are difficult to parse, due to the lot of BS and Space characters. But I agree with you. It is not really necessary to fix that problem, as it's not really a bug. I repeat that personally, I don't need a modification, but it might be useful to implement it for others.

Libeluratio

20th March 2015, 11:31

Hi everyone,

Trying to make wavs from dolby atmos file, I get these:
[libav] Lossless check failed - expected 00, calculated d7. <WARNING>
[libav] Lossless check failed - expected 00, calculated 71. <WARNING>
[libav] Lossless check failed - expected 00, calculated dc. <WARNING>
[libav] Lossless check failed - expected 00, calculated b2. <WARNING>
[libav] Lossless check failed - expected 00, calculated 24. <WARNING>
[libav] Lossless check failed - expected 00, calculated 78. <WARNING>
[libav] Lossless check failed - expected 00, calculated cb. <WARNING>
[libav] Lossless check failed - expected 00, calculated ee. <WARNING>
[libav] Lossless check failed - expected 00, calculated d6. <WARNING>
[libav] Lossless check failed - expected 00, calculated c0. <WARNING>
[libav] Lossless check failed - expected 00, calculated de. <WARNING>
[libav] Lossless check failed - expected 00, calculated 55. <WARNING>
[libav] Lossless check failed - expected 00, calculated b2. <WARNING>
[libav] Lossless check failed - expected 00, calculated a5. <WARNING>
[libav] Lossless check failed - expected 00, calculated a3. <WARNING>
[libav] Lossless check failed - expected 00, calculated 1f. <WARNING>
[libav] Lossless check failed - expected 00, calculated 8a. <WARNING>
[libav] Lossless check failed - expected 00, calculated 6e. <WARNING>
[libav] Lossless check failed - expected 00, calculated 2e. <WARNING>
Original audio track, L+C+LFE+BL+BR+SL: max 24 bits, average 20 bits.
Original audio track, R+SR: constant bit depth of 21 bits.

I've got an updated version of ffmepg.

Sorry if that was already answered (I didn't manage to find answer to that), but is this a normal behaviour ? Will my wav files be corrupted ?

Thank you !

madshi

20th March 2015, 12:44

Ok, I'll keep the console output the way it is for now, thanks for the feedback.

@Libeluratio, is that a seamless branching Blu-Ray? This "lossless check failed" message is expected to appear once for each m2ts part. Have a look at of how many m2ts parts your movie playlists consists. If it's around 19, you should be fine.

Libeluratio

20th March 2015, 13:35

Indeed, I extracted the TrueHD stream with TSMuxer from a The Hunger Games Mockingjay: Part 1 BD. The movie is indeed composed of 20 m2ts files (so 19 divisions), so you're saying this behaviour of having 19 "Lossless check failed" is normal ? There will no be any sync problem or audio artefacts/dropouts etc ?

Thank you !

madshi

20th March 2015, 13:53

Well, it's better to let eac3to work with the original Blu-Ray files to give it full control. I don't know how TSMuxer deals with audio overlaps.

Libeluratio

20th March 2015, 15:20

Ok, thanks madshi for your answers. I'll use exclusively eac3to for handling streams from bluray from now on in order to avoid issues.

EDIT:

I will try with the original Bluray tomorrow, but today I tried with the mkv (that I made with the help of tsmuxer) to handle this problematic Atmos file withe eac3to. I tried two times: first with the HD-DVD/Blu-ray Stream Extractor v0.8.3771, and second with command lines. and the two results seems different !

1 - Log From HD-DVD/Bluray Stream Extractor v0.8.3771:

eac3to v3.28
command line: "C:\eac3to\eac3to.exe" "D:\HG\HG.mkv" 3:"D:\HG\wavs direct gui\1_3_audio.wavs" -down6 -progressnumbers
------------------------------------------------------------------------------
MKV, 1 video track, 3 audio tracks, 3 subtitle tracks, 2:02:49, 24p /1.001
1: h264/AVC, 1080p24 /1.001 (16:9)
2: AC3, French, 5.1 channels, 640kbps, 48kHz
"VFQ 5.1 640 Kbps"
3: TrueHD (Atmos), English, 7.1 channels, 48kHz
"VOA TrueHD 7 719 Kbps"
4: AC3, English, 5.1 channels, 640kbps, 48kHz
"VOA 5.1 640 Kbps"
5: Subtitle (PGS), English, "Complet"
6: Subtitle (PGS), English, "Complet SDH"
7: Subtitle (PGS), French, "Complet"
[a03] Extracting audio track number 3...
[a03] Decoding with libav/ffmpeg...
[a03] Mixing surround channels...
[a03] Writing WAVs...
[a03] Creating file "D:\HG\wavs direct gui\1_3_audio.L.wav"...
[a03] Creating file "D:\HG\wavs direct gui\1_3_audio.R.wav"...
[a03] Creating file "D:\HG\wavs direct gui\1_3_audio.LFE.wav"...
[a03] Creating file "D:\HG\wavs direct gui\1_3_audio.SL.wav"...
[a03] Creating file "D:\HG\wavs direct gui\1_3_audio.C.wav"...
[a03] Creating file "D:\HG\wavs direct gui\1_3_audio.SR.wav"...
[a03] Original audio track, L+C+LFE+BL+BR+SL: max 24 bits, average 20 bits.
[a03] Original audio track, R+SR: constant bit depth of 21 bits.
[a03] Processed audio track, L+C+LFE+SL+SR: max 24 bits, average 21 bits.
[a03] Processed audio track, R: constant bit depth of 21 bits.
Video track 1 contains 176684 frames.
eac3to processing took 10 minutes, 27 seconds.
Done.

2 - Log from cmd line:

eac3to v3.28
command line: "C:\eac3to\eac3to.exe" "D:\HG\HG.mkv" 3:"D:\HG\wavs direct cmd\1_3_audio.wavs" -down6 -progressnumbers
------------------------------------------------------------------------------
MKV, 1 video track, 3 audio tracks, 3 subtitle tracks, 2:02:49, 24p /1.001
1: h264/AVC, 1080p24 /1.001 (16:9)
2: AC3, French, 5.1 channels, 640kbps, 48kHz
"VFQ 5.1 640 Kbps"
3: TrueHD (Atmos), English, 7.1 channels, 48kHz
"VOA TrueHD 7 719 Kbps"
4: AC3, English, 5.1 channels, 640kbps, 48kHz
"VOA 5.1 640 Kbps"
5: Subtitle (PGS), English, "Complet"
6: Subtitle (PGS), English, "Complet SDH"
7: Subtitle (PGS), French, "Complet"
[a03] Extracting audio track number 3...
[a03] Decoding with libav/ffmpeg...
[a03] Mixing surround channels...
[a03] Writing WAVs...
[a03] Creating file "D:\HG\wavs direct cmd\1_3_audio.L.wav"...
[a03] Creating file "D:\HG\wavs direct cmd\1_3_audio.R.wav"...
[a03] Creating file "D:\HG\wavs direct cmd\1_3_audio.SR.wav"...
[a03] Creating file "D:\HG\wavs direct cmd\1_3_audio.SL.wav"...
[a03] Creating file "D:\HG\wavs direct cmd\1_3_audio.C.wav"...
[a03] Creating file "D:\HG\wavs direct cmd\1_3_audio.LFE.wav"...
[a03] [libav] Lossless check failed - expected 00, calculated d7. <WARNING>
[a03] [libav] Lossless check failed - expected 00, calculated 71. <WARNING>
[a03] [libav] Lossless check failed - expected 00, calculated dc. <WARNING>
[a03] [libav] Lossless check failed - expected 00, calculated b2. <WARNING>
[a03] [libav] Lossless check failed - expected 00, calculated 24. <WARNING>
[a03] [libav] Lossless check failed - expected 00, calculated 78. <WARNING>
[a03] [libav] Lossless check failed - expected 00, calculated cb. <WARNING>
[a03] [libav] Lossless check failed - expected 00, calculated ee. <WARNING>
[a03] [libav] Lossless check failed - expected 00, calculated d6. <WARNING>
[a03] [libav] Lossless check failed - expected 00, calculated c0. <WARNING>
[a03] [libav] Lossless check failed - expected 00, calculated de. <WARNING>
[a03] [libav] Lossless check failed - expected 00, calculated 55. <WARNING>
[a03] [libav] Lossless check failed - expected 00, calculated b2. <WARNING>
[a03] [libav] Lossless check failed - expected 00, calculated a5. <WARNING>
[a03] [libav] Lossless check failed - expected 00, calculated a3. <WARNING>
[a03] [libav] Lossless check failed - expected 00, calculated 1f. <WARNING>
[a03] [libav] Lossless check failed - expected 00, calculated 8a. <WARNING>
[a03] [libav] Lossless check failed - expected 00, calculated 6e. <WARNING>
[a03] [libav] Lossless check failed - expected 00, calculated 2e. <WARNING>
[a03] Original audio track, L+C+LFE+BL+BR+SL: max 24 bits, average 20 bits.
[a03] Original audio track, R+SR: constant bit depth of 21 bits.
[a03] Processed audio track, L+C+LFE+SL+SR: max 24 bits, average 21 bits.
[a03] Processed audio track, R: constant bit depth of 21 bits.
Video track 1 contains 176684 frames.
eac3to processing took 10 minutes, 17 seconds.
Done.

As you can see, the "Lossless check failed" Warnings only appears when I do not use the GUI. Maybe this is only a verbose logging difference ?

Also, the 6 channels are not created in the same order in the two cases, I don't know why and if this is important ?

Anakunda

23rd March 2015, 10:10

This message certainly suxx on latest eac3to update:

A monitor program has been found running in your system. Please, unload it from memory and restart your program.

Of course I don't know what I should uninstall or unload, there's nothing monitoring or something eac3to is too paranoid. It seems this message appears only if decoding DTS MA using ArcSoft. AC3 went fine.

madshi

23rd March 2015, 10:30

@Libeluratio, the order of the WAV file creation shouldn't matter. Not sure, though, why you don't get the warnings with the GUI.

@Anakunda, this message doesn't come from eac3to. Must be from ArcSoft, I would guess...

Anakunda

23rd March 2015, 11:38

@Anakunda, this message doesn't come from eac3to. Must be from ArcSoft, I would guess...

Yep it looks so. Anyway it didn't happen previously with ArcSoft, any info leading to remove the reason of this message would be helpful since the ArcSoft is deactivated in this case

The ArcSoft and Sonic decoders don't seem to work, will use libav instead.
The libav DTS decoder doesn't decode the full DTS-HD information. <WARNING>

Groucho2004

23rd March 2015, 11:41

This message certainly suxx on latest eac3to update:

A monitor program has been found running in your system. Please, unload it from memory and restart your program.
Do you use IObit malware fighter or some similar crapware?

Anakunda

23rd March 2015, 11:46

IObit malware fighter or some similar nonsense?
exactly :D

I have installed MBAM and Superantispyware however both in passive mode + Comodo personal firewall (HIPS didn't seem to conflict with EAC3to, not using HIPS)

Anyone can confirm if latest MBAM blocks Arcosft decoders? Not updated anything else.

r0lZ

23rd March 2015, 13:33

I have MBAM free (also in passive mode) and I have never noticed problems with the Arcsoft decoders. I don't use IObit.

Anakunda

23rd March 2015, 16:20

MBAM 2.1.4 Premium uninstalled and ArcSoft is working again

madshi

25th March 2015, 21:58

eac3to v3.29 released

http://madshi.net/eac3to.zip

* added libDcaDec decoder for DTS decoding, new default for 7.x tracks
* fixed: #086: left/right eye information was inverted in some 3D Blu-Rays
* fixed: #263: decoding TrueHD Atmos with active dialnorm information failed
* fixed: #264: using "-float32 -normalize" didn't work in all cases
There's good and bad news. Let's start with the bad news:

We already knew that "7.1 (strange setup)" DTS-HD Master Audio tracks were not decoded correctly by the ArcSoft decoder. Recently I learned that also some other DTS-HD Master Audio 7.1 tracks may not have been decoded correctly. Basically there are 3 possible speaker configurations for 7.1 MA, one of them is the "strange setup", the other two eac3to has not specifically marked. One of them was decoded perfectly by ArcSoft - but only with some dtsdecoder.dll versions, not with all (with some old 1.1.0.0 versions the surround and back channels were swapped, but otherwise lossless). And one speaker config seems to have been decoded by ArcSoft correctly, but then post-processed, with some mixing going on. Basically this means, to be safe I'd recommend to redo all DTS-HD Master Audio 7.1 tracks. I'm sorry about that, and not very happy myself.

The good news is that there's a new open source DTS decoder (dcadec (https://github.com/foo86/dcadec)) available, which in its current form has the following advantages and disadvantages compared to ArcSoft:

+ it's faster
+ it never post-processes, for any channel/speaker configs
+ it can decode all three 7.1 configurations perfectly
+ eac3to can run multiple decoding tasks in parallel
- it's not that well tested yet
- it doesn't support 192kHz decoding yet
- it doesn't support XSA / LBR low bitrate tracks yet

The latest eac3to build now automatically switches to dcadec for all DTS 7.x tracks. However, because the new decoder isn't that well tested yet, for all other channel configurations ArcSoft is currently still the default decoder option (if it's available, otherwise dcadec becomes default).

I'd like to ask all of you eac3to users to stress-test the new dcadec decoder as much as you can. Throw any and all DTS tracks at it and check whether they decode completely and whether the final results appear to be correct. The decoder is supposed to error out if there's any kind of problem during stream parsing or decoding. So normally we should expect the results to be perfect as long as decoding completes. But I would still like to ask you to double check, just to be safe. You can force eac3to to use dcadec by using the "-dcadec" switch. Or by renaming or deleting the ArcSoft decoder. Please make sure that you really test the dcadec decoder and not accidently ArcSoft. I say this because ArcSoft is still the default decoder, so if you don't take extra care, you'll test ArcSoft instead of dcadec.

If you find any problems, could you please report them directly to the dcadec (https://github.com/foo86/dcadec) developer? The "libdcadec.dll" used by eac3to is a direct compile of the official source code. No patches or other modifications. So as long as the interface stays compatible (and I think it will, even "forever"), you can replace the eac3to libdcadec.dll with your own compilation. So if dcadec improves in some way, you won't need a new eac3to version, just compile a new libdcadec.dll.

sl1pkn07

25th March 2015, 22:05

http://www.videolan.org/developers/libdca.html (?)

madshi

25th March 2015, 22:09

@sl1pkn07, what are you trying to say? No, that is not the decoder eac3to is using, if that's your question? Click on "dcadec" in my previous post.

Anakunda

25th March 2015, 22:12

Is dcadec library up to pair with ArcSoft for quality of decoding?

madshi

25th March 2015, 22:18

In theory it should be on par or better. Obviously you can't improve quality for lossless decoding, other than decoding correctly. And there dcadec should be better for 7.1 (because ArcSoft is buggy with that) and on par for all other channel configurations. For lossy decoding I don't know for sure if ArcSoft internally does integer or floating point decoding. If it's integer decoding, dcadec should be slightly superior. Otherwise it might be equal.

sl1pkn07

25th March 2015, 22:21

@madashi is not the same project? dcaenc is a fork?

EDIT: https://github.com/foo86/dcadec/issues/15

oks

Anakunda

25th March 2015, 22:53

Conversion to Opus went fine :cool: and channel mappings seem same as source however I don't have 7.1 "strange setup"

if out there a movie having strange setup I might give a try tomorrow.

nevcairiel

25th March 2015, 23:30

dcadec will silently make strange-setup go away, and decode it perfectly lossless as any other 7.1 sample. :)

Nebudchanezzer

25th March 2015, 23:30

Conversion to Opus went fine :cool: and channel mappings seem same as source however I don't have 7.1 "strange setup"

if out there a movie having strange setup I might give a try tomorrow.

eac3to does opus too now?

Tested with the "strange setup"-track from Black Hawk Down and eac3to didn't default to dcadec.

Gonna do some more testing with this track tomorrow.

Snowknight26

26th March 2015, 01:18

Does dcadec report decoding errors? If yes, I'll see if I can throw every DTS-HD MA track I have at it to see what fails.

kasper93

26th March 2015, 01:41

Yes, eac3to uses strict mode. Decoding will be aborted upon errors. Though best way to test is decode with both ArcSoft and dcadec and compare resulting files. If they are not bit exact, that means one of decoders did something wrong.

Boulder

26th March 2015, 05:06

Thanks madshi, will give the new decoder some work to do soon to compare with Arcsoft :)

EDIT: by the way, you might want to replace libFLAC.dll with a more recent one as there's been a new version out for some time now.

Libeluratio

26th March 2015, 07:39

Hi, thank you madshi for the update.

For my truehd Atmos problem, forget it, it seems that when I extract / convert it into wavs directly from original bluray, the only message I get is the classic "Skipping identical AC3 Frames", and no more the "Lossless check failed" messages.

About the eac3to update, you talked about 7.1 DTS-HD tracks but with 6.1 DTS-HD decoding, did you learn problems with the Arcsoft decoder v1.1.0.0 (that was listed here to be the one to use to bit-perfect decode 6.1 tracks) or any other version of it ?

And for 5.1 DTS-HD tracks, can we stay with any version of Arcsoft decoder ? Thanks !

madshi

26th March 2015, 08:31

eac3to does opus too now?

Tested with the "strange setup"-track from Black Hawk Down and eac3to didn't default to dcadec.
No, Opus is not supported directly by eac3to.

Stupid me. I've enabled dcadec by default for the "7.1" and "7.0" channel strings, but not for the "7.1 (strange setup)" channel string. Argh...

EDIT: by the way, you might want to replace libFLAC.dll with a more recent one as there's been a new version out for some time now.
Atm, I'm only fixing what is broken (like 7.1 ArcSoft DTS decoding).

About the eac3to update, you talked about 7.1 DTS-HD tracks but with 6.1 DTS-HD decoding, did you learn problems with the Arcsoft decoder v1.1.0.0 (that was listed here to be the one to use to bit-perfect decode 6.1 tracks) or any other version of it ?

And for 5.1 DTS-HD tracks, can we stay with any version of Arcsoft decoder ? Thanks !
AFAIK ArcSoft decodes 5.1 and 6.1 just fine. But please do test and compare.

Yoshi

26th March 2015, 13:53

And there dcadec should be better for 7.1 (because ArcSoft is buggy with that) and on par for all other channel configurations.

Maybe I missed something, but for me, the contradiction between your efforts and the one of the MakeMKV developers is still unsolved for me.

I mean, you seem to struggle to workaround one issue or the other, the Arcsoft DTS-decoder allegedly has depending on the version, while the MakeMKV-guys claim "throw in any version of the dtsdecoder.dll and it will be okay".

Furthermore, why does eac3to still require the asaudio.ax filter to be registered in the system (and checkactivate.dll in addition) whereas MakeMKV by a fact only requires the more or less "pure core" of this component?

Sparktank

26th March 2015, 15:08

while the MakeMKV-guys claim "throw in any version of the dtsdecoder.dll and it will be okay".

IIRC, MakeMKV works on API level of Arcsoft.
If you search this thread, you'll find several posts that detail the differences.

Yoshi

26th March 2015, 15:38

I don't see how this is supposed to answer any of my questions. I know that eac3to and MakeMKV - obviously - access the Arcsoft decoder differently, but that's not the point.

The point is, that eac3to achieves worse results than MakeMKV, at least when it comes to 7.1 strange setups. Apparently, there is a technically better way to access the decoders from Arcsoft and thus the question arises why - without any accusation whatsoever - Madshi isn't able to do it but the MakeMKV-guys somehow are.

I've searched this thread again as you suggested and the last statement from Madshi is this one:

It's quite possible that the Chinese API bit is true. But the only practical consequence is that when picking a good dtsdecoder.dll version, you'll still get 100% bit perfect files with eac3to for 99.9% of all DTS-HD Master Audio files, with the only exception being those rare "strange setup" files, which eac3to explicitly warns you about (so you know when you hit those 0.1%). And even those decode "ok" (just too low volume), as explained by tebasuna51.

Stereodude

26th March 2015, 15:45

AFAIK ArcSoft decodes 5.1 and 6.1 just fine. But please do test and compare.
I had a 6.1 DTS-HD MA sample that didn't decode correctly with Arcsoft (but worked fine with hardware decoders in a receiver). I posted about it in the thread back in Sep 2013. I haven't tried it with dcadec yet, but I will soon.

sl1pkn07

26th March 2015, 16:03

EDIT: by the way, you might want to replace libFLAC.dll with a more recent one as there's been a new version out for some time now.

Atm, I'm only fixing what is broken (like 7.1 ArcSoft DTS decoding).

and when have a vulnerability?

https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-8962

eac3to ship a libflac 1.2.1

and the CVE is fixed in 1.3.1 https://xiph.org/flac/changelog.html

Bigmango

26th March 2015, 16:12

eac3to v3.29 released

I'd like to ask all of you eac3to users to stress-test the new dcadec decoder as much as you can.

Is there somewhere a list of movies with 7.1 strange setup?

I'm asking because I remember some of my movies had this but I don't remember which ones...

nevcairiel

26th March 2015, 16:14

The point is, that eac3to achieves worse results than MakeMKV, at least when it comes to 7.1 strange setups. Apparently, there is a technically better way to access the decoders from Arcsoft and thus the question arises why - without any accusation whatsoever - Madshi isn't able to do it but the MakeMKV-guys somehow are.

It seems pointless to re-hash that discussion now, at the point where we have a free and open-source decoder, which should be superior in all ways once its properly tested.

Nebudchanezzer

26th March 2015, 17:15

OK, further tests with the "strange setup"-track from Black Hawk Down:

Decoded the track to wavs using the Sonic decoder and all comparable channels are bitperfect to the ones decoded using dcadec.
For obvious reasons I cannot compare the backchannels this way and I don't have the tools to decode the backchannels properly.

Stereodude

27th March 2015, 00:46

I had a 6.1 DTS-HD MA sample that didn't decode correctly with Arcsoft (but worked fine with hardware decoders in a receiver). I posted about it in the thread back in Sep 2013. I haven't tried it with dcadec yet, but I will soon.
So dcadec doesn't decode this particular 6.1 DTS-HD MA track correctly either. It is bit identical to the Arcsoft's output though. :(

It really is DTS-HD MA 6.1 discrete with audio in each channel. Here's what my Denon says about it:

http://i.imgur.com/rdqQN5t.jpg

However, both Arcsoft and dcadec output an empty back center channel and seems to mess up the LFE channel (there's a bunch of high frequency content in it and it has an overall low volume [very different from decoding the core]).

Edit: Here is a 50MB sample (https://www.sendspace.com/file/31nlcl).

nevcairiel

27th March 2015, 00:50

So dcadec doesn't decode this particular 6.1 DTS-HD MA track correctly either. It is bit identical to the Arcsoft's output though. :(

And how do you know that both are not correct? :p
It seems unlikely that both would be wrong and then even agree on the wrong-ness.

Stereodude

27th March 2015, 01:13

And how do you know that both are not correct? :p
It seems unlikely that both would be wrong and then even agree on the wrong-ness.
Oh, I don't know... Probably because DTS-HD MA capable receivers decode the track correctly. :p

I've tried it on multiple receivers / pre-processors that support DTS-HD MA over HDMI and they all decode a discrete back center channel (with audio in it) as well as not screwing up the LFE.

tebasuna51

27th March 2015, 03:45

Test with all of Channel Layouts obtained with DTSHD Master Audio Suite:
A 7.1-L,R,C,LFE,Lss,Rss, Lsr,Rsr
B 7.1-L,R,C,LFE,Ls ,Rs , Lh ,Rh strange
C 7.1-L,R,C,LFE,Ls ,Rs , Lhs,Rhs strange
D 7.1-L,R,C,LFE,Ls ,Rs , Lsr,Rsr strange
E 7.1-L,R,C,LFE,Ls ,Rs , Cs ,Ch strange
F 7.1-L,R,C,LFE,Ls ,Rs , Cs ,Oh strange
G 7.1-L,R,C,LFE,Ls ,Rs , Lw ,Rw (see 3)
H 7.0-L,R,C, ,Lss,Rss, Lsr,Rsr (bug 1)
I 6.1-L,R,C,LFE,Ls ,Rs , Cs discrete
J 6.1-L,R,C,LFE,Ls ,Rs ,(Cs) matrix
K 6.0-L,R,C, ,Ls ,Rs , Cs discrete
L 6.0-L,R,C, ,Ls ,Rs ,(Cs) matrix
M 5.1-L,R,C,LFE,Ls ,Rs
N 5.0-L,R,C, ,Ls ,Rs
O 4.1-L,R, ,LFE,Ls ,Rs
P 4.1-L,R,C,LFE, , , Cs (see 2)
Q 4.0-L,R, , ,Ls ,Rs ,
R 4.0-L,R,C, , , , Cs (see 2)
S 3.1-L,R,C,LFE
T 3.1-L,R, ,LFE, , , Cs (see 2)
U 3.0-L,R,C
V 3.0-L,R, , , , , Cs (see 2)
W 2.1-L,R, ,LFE
X 2.0-L,R
Y 2.0-Lt,Rt
Z 1.0- , ,C mono

See the attached image.
Decoded with ArcSoft (dtsdecoderdll.dll v1.1.0.0 25-04-2008, reject other date), and libdcadec.dll.

1) eac3to-ArcSoft Bug with Layout H (7.0)
eac3to H70.dtshd
-----------------------------------------------------------------
DTS Master Audio, 6.1 channels, 24 bits, 48kHz (Must be 7.0)
(core: DTS, 5.0 channels, 1509kbps, 48kHz) (5.0 ok)

ArcSoft decoded like 7.0 (FL FR FC BL BR SL SR) but with wrong channel mix:
FL = 0.6335 x L + 0.2327 x Lss
FR = 0.6335 x R + 0.2327 x Rss
FC = 0.6335 x C
BL = empty
BR = 0.3890 x Lsr + 0.5892 x Lss
SL = 0.3890 x Rsr + 0.5892 x Rss
SR = 0.5000 x Lsr + 0.5000 x Rsr

DcaDec decoded all ok.

2) Rest of Layouts I-Z (6.1 to 1.0)
Bit identical ouput between ArcSoft and DcaDec. All ok.
Only this 4 have a little difference:

P 4.1-L,R,C,LFE,Cs
R 4.0-L,R,C, ,Cs
T 3.1-L,R, ,LFE,Cs
V 3.0-L,R, , ,Cs

Checked with sources the ArcSoft decoded channel Cs have differences of -79dB
The DcaDec output is bit identical with the source.

3) Layouts A-G (7.1)
I only see in BD's layouts A, D (strange setup) and G (seems the other than madshi say like not specifically marked).
Before to see the problems we must know the Channel equivalence betwenn DTS channels and WAV channels:

DTS WAV Speaker Position
---- --- ---------------------
L = FL Front Left
R = FR Front Right
C = FC Front Center
LFE = LF (Low Frequency (Efects))
Lsr = BL Back Left
Rsr = BR Back Right
(Lw) = FLC Front Left of Center
(Rw) = FRC Front Right of Center
Cs = BC Back Center
Lss = SL Side Left
Rss = SR Side Right
Oh = TC TopCenter
Lh = TFL Top Front Left
Ch = TFC Top Front Center
Rh = TFR Top Front Right
Lhs = TBL Top Back Left
- = TBC Top Back Center
Rhs = TBR Top Back Right
Ls = don't exist (can be replaced by SL or BL)
Rs = don't exist (can be replaced by SR or BR)
Like the pair Ls,Lr don't exist in WAV, the output can be aproximated with the pair SL*SR or BL*BR, but remember than is not exact.

- DcaDec decode losslessly all channel layouts, if we accept the change Ls,Rs to SL*SR, but the ChannelMask must be changed in layouts B,C,E and F. In G we must accept the change Lw,Rw -> SL*SR and Ls,Rs -> BL*BR .
- ArcSoft decode losslessly only the standard A layout, make a mix coherent with ChanelMask 1599 in layouts B,C,D and G, I can't understand the mix in layouts E and F.

Detailed info:

3.A) Layout 7.1-L,R,C,LFE,Lss,Rss,Lsr,Rsr
This is the standard layout and work fine with ArcSoft and DcaDec (bit identical output).
The channel equivalence is correct and match the WAV output ChannelMask 1599 (FL FR FC LF BL BR SL SR)

3.B) Layout 7.1-L,R,C,LFE,Ls,Rs,Lh,Rh
Detected by eac3to like "strange setup" and decoded to WAV with ChannelMask 1599 (FL FR FC LF BL BR SL SR)

Decoded by ArcSoft with this mix coherent with the ChannelMask 1559
FL = 0.5858 x L + 0.4142 x Lh
FR = 0.5858 x R + 0.4142 x Rh
FC = 0.5858 x C
LF = 0.5858 x LFE
BL = 0.2751 x Ls
BR = 0.2751 x Rs
SL = 0.5171 x Ls
SR = 0.5171 x Rs

Whit DcaDec all channels are decoded without remix losslessly but the channelmask must be changed to:
22031 (FL FR FC LFE SL*SR TFL TFR)

3.C) Layout 7.1-L,R,C,LFE,Ls,Rs,Lhs,Rhs
Detected by eac3to like "strange setup" and decoded to WAV with ChannelMask 1599 (FL FR FC LF BL BR SL SR)

Decoded by ArcSoft with this mix coherent with the ChannelMask 1559
FL = 0.6290 x L
FR = 0.6290 x R
FC = 0.6290 x C
LF = 0.6290 x LFE
BL = 0.2954 x Ls
BR = 0.2954 x Rs
SL = 0.5553 x Ls + 0.4447 x Lhs
SR = 0.5553 x Rs + 0.4447 x Rhs

Whit DcaDec all channels are decoded without remix losslessly but the channelmask must be changed to:
165391 (FL FR FC LF SL*SR TBL TBR)

3.D) Layout 7.1-L,R,C,LFE,Ls,Rs,Lsr,Rsr
Detected by eac3to like "strange setup" and decoded to WAV with ChannelMask 1599 (FL FR FC LF BL BR SL SR)

Decoded by ArcSoft with this mix coherent with the ChannelMask 1559
FL = 0.6804 x L
FR = 0.6804 x R
FC = 0.6804 x C
LF = 0.6804 x LFE
BL = 0.6804 x Lsr + 0.3196 x Ls
BR = 0.6804 x Rsr + 0.3196 x Rs
SL = 0.6007 x Ls
SR = 0.6007 x Rs

Whit DcaDec all channels are decoded without remix losslessly but remember than the pair SL*SR is not exactly the Ls,Rs.

3.E) Layout 7.1-L,R,C,LFE,Ls,Rs,Cs,Chs
Detected by eac3to like "strange setup" and decoded to WAV with ChannelMask 3855
(FL FR FC LF BC SL SR TC)

Decoded by ArcSoft with this mix not coherent with the ChannelMask 3855 or 1559
FL = 0.5858 x L
FR = 0.5858 x R
FC = 0.5858 x C + 0.4142 x Chs
LF = 0.5858 x LFE
BC = 0.5171 x Ls (seems SL)
SL = 0.2717 x Ls + 0.4142 x Cs (seems BL)
SR = 0.2717 x Rs + 0.4142 x Cs (seems BR)
TC = 0.5171 x Rs (seems SR)

Whit DcaDec all channels are decoded without remix losslessly but the channelmask must be changed to:
9999 (FL FR FC LF BC SL*SR TFC)

3.F) Layout 7.1-L,R,C,LFE,Ls,Rs,Cs,Oh
Detected by eac3to like "strange setup" and decoded to WAV with ChannelMask 9999 (FL FR FC LF BC SL SR TFC)

Decoded by ArcSoft with this mix not coherent with the ChannelMask 3855 or 1559
FL = 0.7232 x L
FR = 0.7232 x R
FC = 0.7232 x C
LF = 0.7232 x LFE
BC = 0.6384 x Ls + 0.3616 x Oh (seems SL)
SL = 0.3397 x Ls + 0.5114 x Cs (seems BL)
SR = 0.3397 x Rs + 0.5114 x Cs (seems BR)
TFC= 0.6384 x Rs + 0.3616 x Oh (seems SR)

Whit DcaDec all channels are decoded without remix losslessly but the channelmask must be changed to:
3855 (FL FR FC LF BC SL*SR TC)

3.G) Layout 7.1-L,R,C,LFE,Ls,Rs,Lw,Rw
Detected by eac3to like standard setup (like A) and decoded to WAV with ChannelMask 1599 (FL FR FC LF BL BR SL SR)

Decoded by ArcSoft with this mix coherent with the ChannelMask 1559
FL = 0.5858 x L + 0.4142 x Lw
FR = 0.5858 x R + 0.4142 x Rw
FC = 0.5858 x C
LF = 0.5858 x LFE
BL = 0.2751 x Ls
BR = 0.2751 x Rs
SL = 0.5171 x Ls + 0.4142 x Lw
SR = 0.5171 x Rs + 0.4142 x Rw

[Whit DcaDec all channels are decoded without remix losslessly but the channelmask must be changed to:
1743 (FL FR FC LF FLC FRC SL*SR)]
EDIT:
I accept madshi comment in http://forum.doom9.org/showthread.php?p=1714925#post1714925
Then:
Whit DcaDec all channels are decoded without remix losslessly and the channelmask 1599 (FL FR FC LF BL BR SL SR), not exact because we make the equivalences:
Lw,Rw -> SL*SR
Ls,Rs -> BL*BR

tebasuna51

27th March 2015, 03:59

Edit: If someone can enlighten me how to trim the DTS-HD MA track I can provide a sample.
Easy, if you want trim the first 56 MB
eac3to original.dthd trim.dts -56mb

nautilus7

27th March 2015, 04:24

Great work tebasuna!

tebasuna51

27th March 2015, 04:33

@madshi
Thanks for the new version, checked also my request:
* fixed: #263: decoding TrueHD Atmos with active dialnorm information failed

Stereodude

27th March 2015, 04:40

Easy, if you want trim the first 56 MB
eac3to original.dthd trim.dts -56mb
Okay, thanks. I've added a sample.

nevcairiel

27th March 2015, 10:30

3.G) Layout 7.1-L,R,C,LFE,Ls,Rs,Lw,Rw
Whit DcaDec all channels are decoded without remix lossely but the channelmask must be changed to:
1743 (FL FR FC LF FLC FRC SL*SR)

This is done intentionally on madshi's request.

The main argument is that FLC/FRC are not the correct channels, because FLC/FRC are the 15° speakers (FL/FR are 30°), which sit between the front center and the front left/right speakers.
That is the wrong spatial order for Lw/Rw, so using SL/SR BL/BR is the closest we can get with the correct spatial order!

I haven't tested any of the setups with height channels myself, but real-world sources probably don't exist for that anyway.

nevcairiel

27th March 2015, 10:37

However, both Arcsoft and dcadec output an empty back center channel and seems to mess up the LFE channel (there's a bunch of high frequency content in it and it has an overall low volume [very different from decoding the core]).

I don't know about the back channel, but having high frequencies in the LFE channel is unfortunately not entirely uncommon in DTS-HD.
Your receiver probably just applies a low-pass filter to get rid of them again.

Receivers are a black box unfortunately, so using them as a "reference" is not easy to validate. Who knows if thats lossless to the source?

Stereodude

27th March 2015, 12:42

I don't know about the back channel, but having high frequencies in the LFE channel is unfortunately not entirely uncommon in DTS-HD.
Your receiver probably just applies a low-pass filter to get rid of them again.

Receivers are a black box unfortunately, so using them as a "reference" is not easy to validate. Who knows if thats lossless to the source?
I understand that high frequency energy can end up in the LFE channel in the lossless formats because they're not band limited. I tried to EQ out the content above 120Hz with a 120dB per octave filter at 120Hz from the LFE channel, but it's still hard to tell how similar the core's LFE and the filtered lossless DTS-HD MA LFE is.

Also of note is that dcadec, libav, and arcsoft don't decode the core correctly either. The back center is still empty. There is most definitely a back center channel full of content in the mix that various receivers decode and output that the various software decoders do not.

nevcairiel

27th March 2015, 13:30

Stereodude

27th March 2015, 13:52

Or your receivers just decide to mix something in there. Its impossible to know, unfortunately.
Another software decoder that produces the result you are expecting would at least be something that can be investigated more easily.
Right, external HW from Denon, Pioneer, & Sherbourn that's conformance tested must have bugs (and the exact same one that creates a channel out of thin air) while open source software that's reversed engineered is perfect. That's clearly the most logical explanation. ;)

Look, as requested, I'm providing a sample that doesn't decode as expected. If no one wants to investigate that's not on me.

Bigmango

27th March 2015, 15:39

Test with all of Channel Layouts obtained with DTSHD Master Audio Suite:

Thanks, now that we have open source I hope you've filed a bug report with dcadec for the few issues.

Nebudchanezzer

27th March 2015, 15:56

Look, as requested, I'm providing a sample that doesn't decode as expected.

Looked through the last pages here but I couldn't find a sample, or are you about to post it...?
Thought I could atleast try and decode it with Sonic and Makemkv and see what result they output.

EDIT: Looked a bit closer an found it!

EDIT2: Dude, whats up with posting executables, chrome blocked it directly.

EDIT3: Second try did not generate an executable....

EDIT4: Sonic, Arcsoft (1.1.0.0), and dcadec all produce bitperfect track.
Next, I'm gonna play it via my receiver and see what happens.

Sparktank

27th March 2015, 16:21

EDIT2: Dude, whats up with posting executables, chrome blocked it directly.

EDIT3: Second try did not generate an executable....

That's SendSpace at work.
With most free file hosts, you have to be absolutely sure what you click next is indeed what you intend to click.

Most free file hosts also have their own free downloader tool, which is often checked by default (if you don't have adblock and other security plugins enabled/installed).

Chrome also blocks a lot of things these days, even for anything legit on SourceForge.

Sparktank

27th March 2015, 16:23

So dcadec doesn't decode this particular 6.1 DTS-HD MA track correctly either. It is bit identical to the Arcsoft's output though. :(

However, both Arcsoft and dcadec output an empty back center channel and seems to mess up the LFE channel (there's a bunch of high frequency content in it and it has an overall low volume [very different from decoding the core]).

Edit: Here is a 50MB sample (https://www.sendspace.com/file/31nlcl).

You should also really use the bug tracker, too.
http://eac3to.bugs.madshi.net/

madshi

27th March 2015, 17:08

Oh, I don't know... Probably because DTS-HD MA capable receivers decode the track correctly. :p

I've tried it on multiple receivers / pre-processors that support DTS-HD MA over HDMI and they all decode a discrete back center channel (with audio in it) as well as not screwing up the LFE.
Is your speaker setup 6.1 or 7.1? Have you disabled any surround processing and Audyssey etc in your receiver?

Thanks, now that we have open source I hope you've filed a bug report with dcadec for the few issues.
In this case it might actually be eac3to's fault. eac3to is currently overwriting the WAV channel mask provided by dcadec.

Test with all of Channel Layouts obtained with DTSHD Master Audio Suite
Thanks very much! :)

You often wrote "lossely". What do you mean with that? I think you rather meant "losslessly"? Or did you mean "lossy" which would be the opposite of "losslessly"?

Would you mind providing the test files you were using for these tests? They would be useful for me, and probably also for the dcadec developer.

Before to see the problems we must know the Channel equivalence betwenn DTS channels and WAV channels
I don't agree with that table. DTS channels "Lw" and "Rw" are defined as 60° in the DTS spec, which is absolutely not how I understand "Front Left/Right of Center". Instead I would say that the DTS channels "Lc" and "Rc" are 15° which I would say is what WAV FLC and FRC mean.

So IMHO all those three typical 7.1 speaker channel configurations which we often see in Blu-Rays should map exactly the way they do now. And I also believe there should be no processing applied to them. I don't think the encoding houses are actually aiming for specific angles when they encode the tracks. I think they're rather rolling the dice and they always choose the layout they usually do, or by random. I think the three different 7.1 speaker channel configurations in real life make no difference.

All those weird channel configurations with height speakers etc are definitely incorrect in eac3to. That's most probably my fault, not the fault of dcadec. It would be great if you could create a bug entry for that, so I won't forget about it the next time I work on eac3to.

So your final conclusion would be that dcadec has losslessy decoded all tracks, and the only problem you found were channel masks you were not fully happy with? Ok, to be honest, I'm not sure how to handle those speaker configs with height channels. But I've never seen any such track in real life on any Blu-Ray yet, so it's probably not overly important.

tebasuna51

27th March 2015, 17:10

The main argument is that FLC/FRC are not the correct channels, because FLC/FRC are the 15° speakers (FL/FR are 30°), which sit between the front center and the front left/right speakers.
That is the wrong spatial order for Lw/Rw, so using SL/SR BL/BR is the closest we can get with the correct spatial order!

Then you sugest:

Lw,Rw (-+45º) -> SL,SR (-+90º-110º)
Ls,Rs (-+120º) -> BL,BR (-+150º)

Maybe is better
Lw,Rw (-+45º) -> FL,FR (-+30º)
L,R (-+30º) -> FLC,FRC (-+15º)
with a remap -4,5,2,3,0,1,6,7 and channelmask 1743

BTW, with this sources I recommend make a downmix to 5.1
FL = L + Lw
FR = R + Rw

madshi

27th March 2015, 17:36

Then you sugest:

Lw,Rw (-+45º) -> SL,SR (-+90º-110º)
Ls,Rs (-+120º) -> BL,BR (-+150º)

Maybe is better
Lw,Rw (-+45º) -> FL,FR (-+30º)
L,R (-+30º) -> FLC,FRC (-+15º)
with a remap -4,5,2,3,0,1,6,7 and channelmask 1743
The DTS channels we're talking about are C L R Ls Rs LFE Lw Rw, which are: 0°, 30°, 60°, 110°, as far as I understand. The WAV channels don't have a specific angle assigned to them, so we can only guess what they mean. I would say we should assign the recommended 7.1 speaker angles to them, as a reasonable approximation. So WAV channels FL FR FC LFE SL SR BL BR would map to 0°, 22-30°, 90-110°, 135-150°. We don't have a WAV channel which maps to 60°. So I believe the best match is to assign DTS 0°, 30°, 60°, 110° to WAV 0°, 30°, 90-110°, 135-150°. Yes, it's not an exact match, but I think it's a reasonable choice. The only other reasonable choice would be to remap L/R to FLC/FRC and to remap Lw/Lw to FL/FR. But if we do that we flatten the surround sound. The Lw/Rw channels are supposed to create some sort of "surround" feeling. If we assign them to FL/FR, 5 of the 7 channels are just creating a more detailed stereo field with no surround feeling at all. I don't think that makes a lot of sense.

Furthermore, as mentioned before: I don't think movie studios are doing separate mixes for separate encoding houses. I think movie studios are likely sending their 7.1 masters to the encoding houses, and they just pick "by random" either PCM, TrueHD or DTS-MA. And if they decide to use DTS-MA, they probably by random select one of the 3 different speaker configs. I don't think the encoding houses are remixing the audio master they got from the studio, based on which speaker config in the DTS-MA is selected. I don't have proof for this, but I think this is very likely. So choosing the same normal WAV channel mask for all these 3 DTS speaker assignments is IMHO the best solution in real life, although it does mean we're "ignoring" the exact speaker angles encoded in the DTS-MA stream. But as I said, I don't think they have any meaning in real life (= Blu-Ray), anyway.

Stereodude

27th March 2015, 18:33

Is your speaker setup 6.1 or 7.1? Have you disabled any surround processing and Audyssey etc in your receiver?
Speaker setup is 7.1. AFAIK, DTS-ES duplicates the back center to the back left and back right in such a setup. I've tested this sample on both my Pioneer Elite and Denon with all processing disabled (even bass management & time alignment) using Pure Direct. There are no silent speakers.

It should be easy to eliminate possibility of a receiver/processor bug for this clip. Someone with the DTS encoder can encode the lossless output from dcadec (or Arcsoft) back to a DTS-ES discrete core + DTS-HD MA stream and I can play it back through my receiver and see if the rear channels are silent or not.

Nebudchanezzer

27th March 2015, 19:43

tebasuna51

28th March 2015, 04:32

...So I believe the best match is to assign DTS 0°, 30°, 60°, 110° to WAV 0°, 30°, 90-110°, 135-150°...
Ok, but, like DcaDec decode lossely all the channels, each user can do the mix or changes at their preference.

For that the more important question is identify the channel layout. We can't mistake the A layout with the G layout or all the rest with "strange".

Can eac3to supply this info?

madshi

28th March 2015, 09:33

Speaker setup is 7.1. AFAIK, DTS-ES duplicates the back center to the back left and back right in such a setup. I've tested this sample on both my Pioneer Elite and Denon with all processing disabled (even bass management & time alignment) using Pure Direct. There are no silent speakers.

It should be easy to eliminate possibility of a receiver/processor bug for this clip. Someone with the DTS encoder can encode the lossless output from dcadec (or Arcsoft) back to a DTS-ES discrete core + DTS-HD MA stream and I can play it back through my receiver and see if the rear channels are silent or not.
The 6.1 back center channel in supposed to be exactly in the middle of the back wall. While the 7.1 back channels are supposed to be nearer to the corners of the back wall. Because of that I think it's likely that the receivers are trying to simulate a 6.1 speaker setup by mixing the surround channels and the back center channel for playback on the 7.1 back channels. So I think what you're hearing is probably the surround channels being mixed into the 7.1 back channels. But of course this is only a guess.

There are 2 ways how we could test this:

1) You could temporarily convert your setup to 6.1. Not sure if you'd be willing to do that, considering that you'd have to modify your receiver setup etc, and you might lose Audyssey calibration etc.

2) Does anybody have a 6.1 channel test DTS-MA file? Playing this back on your receiver should also be interesting. You would learn exactly which 6.1 DTS-MA channel is played back by your receiver on which speaker(s).

Ok, but, like DcaDec decode lossely all the channels, each user can do the mix or changes at their preference.

For that the more important question is identify the channel layout. We can't mistake the A layout with the G layout or all the rest with "strange".

Can eac3to supply this info?
So basically you'd like eac3to to print out the DTS speaker config? That should be very easy. You can already use "-logdts" to get the speaker config right now. I'd just have to copy the information (maybe is somewhat prettier form) to the default output.

EDIT: As this is an eac3to-thread, I would kindly ask if there is an easy possibilty to add support for opus-encoding, from the tests I've seen on avs-forum opus outperforms mp3 and AAC.
I don't have the time to add new features atm, unless they're absolutely crucial for basic Blu-Ray remuxing.

SeeMoreDigital

28th March 2015, 11:07

madshi

28th March 2015, 12:16

Yeah, but those are not channel test files. For testing it would be crucial to have a 6.1 DTS-MA file where every channel is played sequentially like "this is the left channel", "this is the right channel" etc.

tebasuna51

28th March 2015, 12:54

2) Does anybody have a 6.1 channel test DTS-MA file? Playing this back on your receiver should also be interesting. You would learn exactly which 6.1 DTS-MA channel is played back by your receiver on which speaker(s).
Channel test 6.1 discrete sample: https://www.sendspace.com/file/l724qo

So basically you'd like eac3to to print out the DTS speaker config? That should be very easy. You can already use "-logdts" to get the speaker config right now. I'd just have to copy the information (maybe is somewhat prettier form) to the default output.

I forget check the "-logdts". Show:
A71 - activeSpeakers C L R LFE Lsr Rsr Lss Rss ($84b)
B71 - activeSpeakers C L R Ls Rs LFE Lh Rh ($2f)
C71 - activeSpeakers C L R Ls Rs LFE Lhs Rhs ($200f)
D71 - activeSpeakers C L R Ls Rs LFE Lsr Rsr ($4f)
E71 - activeSpeakers C L R Ls Rs LFE Cs Ch ($9f)
F71 - activeSpeakers C L R Ls Rs LFE Cs Oh ($11f)
G71 - activeSpeakers C L R Ls Rs LFE Lw Rw ($40f)

For me is enough than you include:
(Layout $84b)
(Layout $2f)
(Layout $200f)
(Layout $4f)
(Layout $9f)
(Layout $11f)
(Layout $40f)

Or:
(C L R LFE Lsr Rsr Lss Rss)
(C L R LFE Ls Rs Lh Rh)
(C L R LFE Ls Rs Lhs Rhs)
(C L R LFE Ls Rs Lsr Rsr)
(C L R LFE Ls Rs Cs Ch)
(C L R LFE Ls Rs Cs Oh)
(C L R LFE Ls Rs Lw Rw)

instead (strange setup)

tebasuna51

28th March 2015, 12:55

EDIT: As this is an eac3to-thread, I would kindly ask if there is an easy possibilty to add support for opus-encoding...

You can use the STDOUT from eac3to to opus-encode.
There are many encoders than can be used this way (Lame, oggenc, ffdcaenc, qaac, ...) eac3to can't support all parameters needed for all encoders.

Use for instance:

eac3to input stdout.wav | opusenc --ignorelength --bitrate 96 - output.opus

(use full paths for eac3to, input, opusenc and output.opus if there aren't in the same folder. Or use a GUI like UsEac3to)

Stereodude

28th March 2015, 15:12

The 6.1 back center channel in supposed to be exactly in the middle of the back wall. While the 7.1 back channels are supposed to be nearer to the corners of the back wall. Because of that I think it's likely that the receivers are trying to simulate a 6.1 speaker setup by mixing the surround channels and the back center channel for playback on the 7.1 back channels. So I think what you're hearing is probably the surround channels being mixed into the 7.1 back channels. But of course this is only a guess.
It seems that your guess is correct. Playback of tebasuna51's test clip does result in some of the side speaker audio being mixed into the corresponding side's rear speakers while the back center signal is duplicated into just both rear speakers.

Since I don't want to lose my Audyssey calibration by switching to a 6.1 setup, at this point I have no way of definitively determining if the blu-ray disc really has a empty rear center channel or not, but it seems most likely.

Libeluratio

28th March 2015, 15:13

I've done a little testing, not sure I understand the results:

1) Source: DTS-HD MA 7.1 (from Exodus BluRay):
- A) to 8 wavs with Arcsoft V1.1.0.0, V1.1.0.8, and dcadec: bit-identical outputs

- B) to 6 wavs (-down6) with Arcsoft V1.1.0.0, V1.1.0.8, and dcadec: bit-identical outputs excepts the surround channels LS and RS: 3 different MD5 for each (but byte identical on windows properties)

==> how is that possible ? in B), LS and RS are created from A) Lsr, Lss, Rsr, Rss, right ? since no matter the decoder used in A), the outputs are bit-identical, how can I get not-bit-identicals LS and RS in B) ??

2) When creating 3 DTS-HD MA files from the 3 A) outputs, I get 3 bit-identical DTS-HD MA files, though not bit-identical to the 1) Source from original Bluray.

When I convert each of them with the 3 decoders, I end with bit-identical files but these are not bit-identical to the A) outputs !

That files where used as inputs to make these DTS-HD MA files, so I think I should get them back as outputs, since DTS-HD MA is lossless and arcsoft dtsdecoder V1.1.0.0, V1.1.0.8, and dcadec are lossless decoders !

Something seems wrong here, maybe it's me not understanding everything ?

Nebudchanezzer

28th March 2015, 16:32

2) When creating 3 DTS-HD MA files from the 3 A) outputs, I get 3 bit-identical DTS-HD MA files, though not bit-identical to the 1) Source from original Bluray.

When I convert each of them with the 3 decoders, I end with bit-identical files but these are not bit-identical to the A) outputs !

That files where used as inputs to make these DTS-HD MA files, so I think I should get them back as outputs, since DTS-HD MA is lossless and arcsoft dtsdecoder V1.1.0.0, V1.1.0.8, and dcadec are lossless decoders !

Something seems wrong here, maybe it's me not understanding everything ?

Maybe I can shed some light on this.
MA-suite adds 1024 samples of audio at the beginning of the audio when encoding (2 frames), you can easily cut them away after encoding, just use eac3to and add a negative delay of 21ms to the encoded dtshd-file.

However I came across something else when testing:
With seamless branching discs eac3to 3.28 and 3.29 produce different results when encoding directly to flac.

If I extract the dtshd-track and then encode it to flac both versions produce bitidentical results but when encoding directly to flac when demuxing 3.28 and 3.29 produce different results, how come?
"The Hunger Games: Catching Fire" US release is what I have encountered this on.

kasper93

28th March 2015, 19:05

@madshi:

This sample is refused by eac3to, but it can be decoded just fine with dcadec. http://forum.doom9.org/showpost.php?p=1715032&postcount=3090

madshi

28th March 2015, 19:41

- B) to 6 wavs (-down6) with Arcsoft V1.1.0.0, V1.1.0.8, and dcadec: bit-identical outputs excepts the surround channels LS and RS: 3 different MD5 for each (but byte identical on windows properties)

==> how is that possible ? in B), LS and RS are created from A) Lsr, Lss, Rsr, Rss, right ? since no matter the decoder used in A), the outputs are bit-identical, how can I get not-bit-identicals LS and RS in B) ??
Mixing requires dithering, which produces different results, because dithering means adding random noise.

However I came across something else when testing:
With seamless branching discs eac3to 3.28 and 3.29 produce different results when encoding directly to flac.

If I extract the dtshd-track and then encode it to flac both versions produce bitidentical results but when encoding directly to flac when demuxing 3.28 and 3.29 produce different results, how come?
"The Hunger Games: Catching Fire" US release is what I have encountered this on.
I'd suggest that you decode to WAV and then compare what the difference is, with both a file comparison tool and an audio WAV tool. Are some bytes different? Or is there's some sort of audio delay in one track? Or what...

@madshi:

This sample is refused by eac3to, but it can be decoded just fine with dcadec. http://forum.doom9.org/showpost.php?p=1715032&postcount=3090
There's a DTSHD encoder header in front of the real DTS audio data. If you remove that, eac3to will accept the file just fine. It's a weird file, though, DTS-MA without a core.

hubblec4

28th March 2015, 20:41

hi madshi

is a support for DTS Express planed?

rapscallion

28th March 2015, 20:57

[code]* added libDcaDec decoder for DTS decoding, new default for 7.x tracks
* fixed: #263: decoding TrueHD Atmos with active dialnorm information failed

Thanks for the new version madshi!

I normally "extract" DTS HD 7.x tracks from the *.m2ts stream. Is that the same thing as "decoding"?

sneaker_ger

28th March 2015, 20:59

is a support for DTS Express planed?
dcadec author said:
might be eventually supported, although I'm not very interested in implementing it.

I normally "extract" DTS HD 7.x tracks from the *.m2ts stream. Is that the same thing as "decoding"?
If the data is copied but stays in dts-hd format it is not decoding, only extracting. In that case this change does not affect you.

rapscallion

28th March 2015, 21:01

Thank you, that's what I was hoping.

Nebudchanezzer

28th March 2015, 22:23

I'd suggest that you decode to WAV and then compare what the difference is, with both a file comparison tool and an audio WAV tool. Are some bytes different? Or is there's some sort of audio delay in one track? Or what...

To start with I did a bitcomparison using foobars tool for just that:

Differences found in compared tracks.
Zero offset detected.

Comparing:
"L:\The.Hunger.Games.Catching.Fire.FLAC.for.comparison.eac3to.3.28.flac"
"L:\The.Hunger.Games.Catching.Fire.FLAC.for.comparison.eac3to.3.29.flac"
Compared 424063871 samples.
Differences found: 1193 values, starting at 6:56.707458, peak: 0.0000610 at 6:56.707583, 8ch
Detected offset as 0 samples.

As you can see both tracks contain the exact same amount of samples but the diffrences begin at 6:56 wich also happens to the be the same time as the first audio-overlap reported by eac3to.
Same thing applies on other seamless branching discs, tried with Divergent as well and it too had diffrencies in the decoded audiotrack between 3.28 and 3.29.

Audio-overlaps reported by eac3to:
[a02] Audio overlaps for 3ms at playtime 0:06:57. <WARNING>
[a02] Audio overlaps for 7ms at playtime 1:33:51. <WARNING>
[a02] Audio overlaps for 10ms at playtime 1:38:54. <WARNING>
[a02] Audio overlaps for 8ms at playtime 1:40:26. <WARNING>
[a02] Audio overlaps for 10ms at playtime 1:40:49. <WARNING>
[a02] Audio overlaps for 6ms at playtime 1:55:50. <WARNING>
[a02] Audio overlaps for 13ms at playtime 1:57:32. <WARNING>

I also decoded the track to wavs and used foobar to compare each channel individually and the conclusion is that the diffrences is found in all channels.

I was sort of going through my old flac files (7.1) to hash out wich ones were decoded improperly by Arcsoft when I stumbled across this, making it hard to compare old tracks vs new.

windiff first diffrences of centerchannel:
http://someimage.com/aJR2FEb

Libeluratio

29th March 2015, 16:07

Thank you madshi and Nebudchanezzer for your explainations.

One test I did:

on the TRON Legacy DTS-HD MA 7.1 track:

BL, BR, C, LFE, SL, SR channels between arcsoft v1.1.0.0, v1.1.0.8, and dcadec are bit-identical, BUT L and R channel are not !

(they are bit-identical between arcsoft v1.1.0.0 and v1.1.0.8 but not with dcadec).

I know this DTS-HD MA track was known to have issues, that is why I tested it.

Here is a sample if you want: https://www.sendspace.com/file/0gha9a

and as Nebudchanezzer did, a picture showing some differences between the two L channels from arcsoft v1.1.0.8 and dcadec for example: http://someimage.com/NUzaDn3

Basically, in the L and R files extracted with dcadec, the differences with L and R extracted from Arcsoft are some values replaces by 00

Can we know if one of the decoders extracted the L and R channels right, and which one ?

tebasuna51

29th March 2015, 16:36

You often wrote "lossely". What do you mean with that? I think you rather meant "losslessly"? Or did you mean "lossy" which would be the opposite of "losslessly"?

Would you mind providing the test files you were using for these tests? They would be useful for me, and probably also for the dcadec developer.

- Of course "losslessly", a typo and copy/paste repeat.

- Here is the full test files DTS-MA: https://www.sendspace.com/file/pd2o0f

tebasuna51

29th March 2015, 17:01

BL, BR, C, LFE, SL, SR channels between arcsoft v1.1.0.0, v1.1.0.8, and dcadec are bit-identical, BUT L and R channel are not !

(they are bit-identical between arcsoft v1.1.0.0 and v1.1.0.8 but not with dcadec).

Here is a sample if you want: https://www.sendspace.com/file/0gha9a

I can't reproduce the problem with your sample.
Output from ArcSoft v1.1.0.0 and DcaDec are bit-identical.

EDIT: Sorry, you are right, I forget use eac3to 3.28
I confirm the differences.

Libeluratio

29th March 2015, 17:13

I can't reproduce the problem with your sample.
Output from ArcSoft v1.1.0.0 and DcaDec are bit-identical.

I don't understand why.

Here is what I get with that sample:

From Arcosft v1.1.0.0:
channel L MD5: d063bd2fa3fc061c53e355e95d0d13ba
channel R MD5: e5ddeb27e0d35932a9298f3802d50f44

From DcaDec
channel L MD5: fe53588e9dbe05b3b58bcdc820daa5ff
channel R MD5: e078126224c5c465b9ee2dff349935a3

And if I compare them with tools like VBinDiff as on the picture attached to my previous post, I see differences a well. What tool are you using to determine the bit-identicalness ?

(Also, I use eac3to v3.28 to extract with arcsoft and eac3to v3.29 to extract with DcaDec as I didn't find a switch like "-arcsoft" to force the use of arcsoft on V3.29 on 7.1 tracks)

Nebudchanezzer

29th March 2015, 17:21

I can't reproduce the problem with your sample.
Output from ArcSoft v1.1.0.0 and DcaDec are bit-identical.

I could, using eac3to 3.28 and arcsoft 1.1.0.0 vs 3.29 and dcadec

However there was no differences found when using 3.29 for both dcadec and Arcsoft.

Could be interesting to try with the sonic decoder as well.

EDIT: Yes the "-arcsoft" switch does not work on 3.29.

EDIT2: Tried with sonic aswell and then compared the left channel and none of the 3 decoders produced the same result....

Libeluratio

29th March 2015, 17:33

EDIT: Yes the "-arcsoft" switch does not work on 3.29.

So basically, you tested two times with DcaDec, thinking one time was with arcsoft, right ?

But then, using 3.28 you where able to use arcsoft and to find same results as me ? I can't try sonic decoder unfortunately

Sparktank

29th March 2015, 17:55

EDIT2: Tried with sonic aswell and then compared the left channel and none of the 3 decoders produced the same result....

Doesn't Sonic just decode 5.1 while dropping the remaining channels?

Nebudchanezzer

29th March 2015, 18:13

So basically, you tested two times with DcaDec, thinking one time was with arcsoft, right ?

But then, using 3.28 you where able to use arcsoft and to find same results as me ? I can't try sonic decoder unfortunately

Yes on both questions.

Doesn't Sonic just decode 5.1 while dropping the remaining channels?

It does, but since Libeluratio already had tested with Arcsoft and dcadec and found that the difference that where found was only in left and right channels, so Sonic should in this case be sufficient to se if I could come up with a result that either matched the Arcsoft or dcadec (only tested Left channel) but it produced a third result.........

So it would be interesting if someone could test with MakeMKV and see what they come up with there.

tebasuna51

29th March 2015, 19:05

So basically, you tested two times with DcaDec, thinking one time was with arcsoft, right ?

But then, using 3.28 you where able to use arcsoft and to find same results as me ?

Yep, before I use 3.29, with 3.28 I have the same results.

EDIT:
MakeMkv: bit-identical to ArcSoft (same dstdecoderdll.dll)

BTW, the differences between ArcSoft and DcaDec aren't audibles (-108 dB)

stax76

29th March 2015, 20:35

@madshi

It's great the external dependency for DTS-HD decoding is gone, if you also want to remove the Haali muxer dependency at one time maybe this project could be helpful:

http://sourceforge.net/projects/yamka

sl1pkn07

29th March 2015, 20:51

that poject sounds great. i hope works ok with wine (linux) through eac3to (if it can be implement)

NikosD

29th March 2015, 21:04

Kurtnoise

30th March 2015, 09:16

why this one specifically ? The matroska muxer from FFmpeg should be fine...

stax76

30th March 2015, 09:55

I don't know either but remember neuron2 was very disappointed from ffmpeg libs and switched to NVIDIA because of it.

the_weirdo

30th March 2015, 11:26

I don't know either but remember neuron2 was very disappointed from ffmpeg libs and switched to NVIDIA because of it.

I didn't expect a long-time developer like you to make assumption like this.

stax76

30th March 2015, 12:25

he said this:

Stopping DGAVCDec has more to do with the serious deficiencies of libavcodec, such as its dropping of good frames (a showstopper for accurate random access), its poor performance, its lack of a native Windows build, and its lack of support

problems were not only technical, I don't have anything more to say here other then that I have very good experience with both ffmpeg and DGDecNV, because of StaxRip I have to focus on free and portable tools though.

Kurtnoise

30th March 2015, 12:30

those comments are depreciated...this is not true nowadays.

nevcairiel

30th March 2015, 12:52

That comment was from 2010, it certainly doesn't apply anymore today.

Atak_Snajpera

30th March 2015, 18:46

Another reason why we should dump ArcSoft Decoder ;)
a05 The Arcsoft DTS Decoder only allows one operation at a time.

Bigmango

31st March 2015, 18:11

Another reason why we should dump ArcSoft Decoder ;)
a05 The Arcsoft DTS Decoder only allows one operation at a time.

This is a problem of eac3to.

Makemkv uses arcsoft and does as many parallel conversions on the fly as you want, with the same arcsoft dll.

... and it does all of this in 1 shot demuxing - correcting audio gaps - converting and remuxing on the fly.

With makemkv I have converted movies with 4 DTS-HDMA tracks to flac in 1 shot without any issues at all.

lolo258

31st March 2015, 23:52

eac3to v3.28 released

Please note that some of these changes have been implemented without a lot of testing. So it would be great if you guys could double check things, especially the changes, to make sure they really work as intended. Also please make sure TrueHD decoding still works losslessly, as usual (even for non-Atmos tracks). I've hacked Atmos "support" into the old ffmpeg version I've been using for years, so I wouldn't have to update to the latest ffmpeg version. Don't have much time atm, so I tried to do the most important stuff with the least amount of work.

Hi, I've done some test on TrueHD and TrueHD with Atmos stream, eac3to can decode pure TrueHD very well, but I've tested 4 Atoms streams, it both shows some differences on bit depth, I don't know if it means lossy or not.

TrueHD track：
http://uploadingit.com/file/uoexuaibbrpd577b/truehd1.jpg

Atmos track-1：
http://uploadingit.com/file/cyebtezhwgkebdfc/atmos1.jpg

Atmos track-2：
http://uploadingit.com/file/mrwk7sehdnhpsfvu/atmos2.jpg

Atmos track-3：
http://uploadingit.com/file/c30qnbiffkbsqthh/atmos3.jpg

Atmos track-4：
http://uploadingit.com/file/stdp0nyozicd2ciz/atmos4.jpg

If you need Atmos streams for testing, please download:

https://mega.co.nz/#!RdYBDLwC!K2tmsD9MatFwEi7YCuVZit0VoAQTAOcfDn4mDGHRO4U

https://mega.co.nz/#!dFQm2agR!JfMupNxapp1PBE_KXFtRnbWzNC7BvFOWzTEsIHr7e2w

https://mega.co.nz/#!pRYXjBza!0hOdOa3oXwlEy40C3U_c4WzICRukxqN_8I4EUmQOvoI

https://mega.co.nz/#!JBZFzZ4J!P2mQcaJi5T6UBMsya_Rvuh-fDHOOOsjjUuMXraD0xrg

madshi

31st March 2015, 23:58

That looks alright to me. It's quite common to see things like that with TrueHD tracks.

lolo258

1st April 2015, 00:35

That looks alright to me. It's quite common to see things like that with TrueHD tracks.

Thanks, because some people in my country who just purchased new Atmos receiver, they don't (want to) believe that PC can use the almighty eac3to to decode Atmos stream, so I need to prove to them.:D

Another question, Do you think Lav Filter 0.64 can decode Atmos stream like eac3to?

:thanks:

Sparktank

1st April 2015, 00:39

decode Atmos

If you mean ignore the Atmos extension and deliver just TrueHD, then it should.

To get actual Atmos audio as it is advertised, you need to play the disc through the BD player to the Atmos-enabled receiver.
And probably check settings in the player so that it reads Atmos audio and not discarding it to deliver regular TrueHD extension.

lolo258

1st April 2015, 05:00

If you mean ignore the Atmos extension and deliver just TrueHD, then it should.

To get actual Atmos audio as it is advertised, you need to play the disc through the BD player to the Atmos-enabled receiver.
And probably check settings in the player so that it reads Atmos audio and not discarding it to deliver regular TrueHD extension.

So your meant eac3to can't actual decode Atmos, but only decode the TrueHD, Thanks.

Sparktank

1st April 2015, 05:28

So your meant eac3to can't actual decode Atmos, but only decode the TrueHD, Thanks.

Taken from the LAV filters thread, regarding any Atmos decoding...
so I guess the only thing now missing is a free Dolby Atmos decoder?That will quite certainly stay missing. Atmos relies on measuring the equipment to achieve optimal utilization.

Since it works in a 3D atmosphere.
Actual 3D with height, width, and depth (not DSP on receivers that create a 'center' speaker using front left+right speakers).
Height is a new aspect for receivers. A seemingly discreet new aspect.

You still get 7.1 (2D; width+depth), though. Which ain't all that bad.

Music Fan

1st April 2015, 16:58

There are also Dolby Atmos trailers there ;
http://www.demo-world.eu/2d-demo-trailers-hd/

I extracted the sound in thd+ac3 and I see with eac3to that it still contains the Atmos extension ; does it mean eac3to can't remove the Atmos extension if one need only True HD ?

Sparktank

1st April 2015, 17:37

does it mean eac3to can't remove the Atmos extension if one need only True HD ?

If you're just extracting (demuxing), it shouldn't be a big deal since anything that can't read Atmos will read just the TrueHD.
Most software is updated to use ffmpeg patch to ignore Atmos and most hardware is already designed to not read the Atmos extension if it's not supported.

nevcairiel

1st April 2015, 19:31

Personally, I wouldn't even know how to reliably remove the Atmos extension, and I wrote the patch for the ffmpeg truehd decoder to ignore it during decoding, so i'm somewhat versed in the topic. It would probably need quite complex bitstream manipulation.

Libeluratio

3rd April 2015, 15:21

Yep, before I use 3.29, with 3.28 I have the same results.

EDIT:
MakeMkv: bit-identical to ArcSoft (same dstdecoderdll.dll)

BTW, the differences between ArcSoft and DcaDec aren't audibles (-108 dB)

Differences may not be audible, but this means that at least one of the two decoders (arcsoft and/or dcadec) is'nt bit-exact decoding the source...

I have an other problem decoding a 5.1 DTS-HD MA file from french Bluray movie "La French". every 6 channels decoded from dcadec is different from the 6 decoded by arcsoft (v1.1.0.8)...!!

Here is a screen I made after opening the Center channels in audacity: top is decoded with dcadec, bottom decoded with arcsoft. It is the same for every other 5 channels (channel decoded with dcadec seems to be at a higher volume).

http://91.68.209.8/bmi/img11.hostingpics.net/pics/398304Capture.jpg

In this case again, at least one of the two decoders is doing wrong

tebasuna51

3rd April 2015, 22:14

Differences may not be audible, but this means that at least one of the two decoders (arcsoft and/or dcadec) is'nt bit-exact decoding the source...

Yes, but we can't know what without the sources.
Please send your samples to DcaDec developers.

By the moment the unique differences I see in my samples the DcaDec was the bit-exact decoder.

madshi

4th April 2015, 08:27

- Here is the full test files DTS-MA: https://www.sendspace.com/file/mtejw5
Thanks! :)

Here is what I get with that sample:

From Arcosft v1.1.0.0:
channel L MD5: d063bd2fa3fc061c53e355e95d0d13ba
channel R MD5: e5ddeb27e0d35932a9298f3802d50f44

From DcaDec
channel L MD5: fe53588e9dbe05b3b58bcdc820daa5ff
channel R MD5: e078126224c5c465b9ee2dff349935a3

And if I compare them with tools like VBinDiff as on the picture attached to my previous post, I see differences a well.
Could you please report this here?

https://github.com/foo86/dcadec/issues

It's great the external dependency for DTS-HD decoding is gone, if you also want to remove the Haali muxer dependency at one time maybe this project could be helpful:

http://sourceforge.net/projects/yamka
There are several MKV muxers available out there. I've no idea which one is "the best". In any case, I currently don't have time to change the MKV muxing. I added dcadec mostly because of the 7.1 decoding issues with ArcSoft. Of course the other advantages of dcadec are welcome, too.

By the moment the unique differences I see in my samples the DcaDec was the bit-exact decoder.
That's what the dcadec developer said, too. I had a couple of samples with which didn't decode bit-by-bit perfectly when comparing ArcSoft and dcadec, and the dcadec developer said then whenever he had this problem, and the original WAV files to compare to, it was dcadec which was bit perfect and not ArcSoft. But this is hard to proof if the original WAV files are not available, of course.

-------

So is there a consensus on dcadec yet? Should I make it the default DTS decoder in eac3to? Opinions?

NikosD

4th April 2015, 08:56

There are several MKV muxers available out there. I've no idea which one is "the best"

For me at least, I don't know for Stax76, the "issue" with Haali muxer is the dependency of the Haali splitter.

You have to install them both at the same time.

If you know a way to install just the muxer, please share.

Also, it's just another external installer dependency of eac3to that we could avoid, using any other equally good project.

madshi

4th April 2015, 09:26

Sure, I also have to hack around to make the Haali Muxer work well (I manually edit/hack the final MKV file to enter the "FPS" information, which is otherwise missing). I would really like to replace the MKV muxer, but my day has only 24hours, and I've so many other things to do. Currently madVR has a higher development priority than eac3to...

stax76

4th April 2015, 10:16

How about this idea, if the Haali COM components are not registered in the system, check if the libraries are in the eac3to folder and use them directly, COM libraries can be used directly, right?

madshi

4th April 2015, 10:39

Hmmmm. Yes, that could work.

tebasuna51

4th April 2015, 11:24

...
So is there a consensus on dcadec yet? Should I make it the default DTS decoder in eac3to? Opinions?
Yes for me.

- With some channelmask changes.
- Not for DTS Express or 192 KHz.
- Make run the -arcsoft parameter to some check.

kasper93

4th April 2015, 11:56

- Not for DTS Express or 192 KHz.

Have you tested it with latest version? 192 KHz is supported now, while DTS Express need still some work.

filler56789

4th April 2015, 12:05

Latest LAV Audio already works for both DTS Express and pure-lossless DTS, therefore I think eac3to could be given another option :)

kasper93

4th April 2015, 12:13

Yeah, it does, but according to dcadec author. Decoding of DTS Express streams still need some work. But 192KHz is done.

Nebudchanezzer

4th April 2015, 15:00

I've posted about this before, but I thoght it hade to do with how eac3to handled overlapping audio in case of a seamless branching disc, but I recently tried it with the new "Taken 3" wich has 5.1 audio and when doing a FLAC-track on the fly (when demuxing) there is diffrences when using either arcsoft or dcadec, but if you extract the DTS-HD MA first and then convert it to flac there is no diffrences.

Comparing:
"L:\Taken.3.Unrated.FLAC.5.1.24bit.from.DTS-HD.MA.arcsoft.flac"
"L:\Taken.3.Unrated.FLAC.5.1.24bit.from.DTS-HD.MA.dcadec.flac"
Compared 332088173 samples.
Differences found: 3670 values, starting at 0:39.455521, peak: 0.0000610 at 0:39.455875, 5ch
Detected offset as 0 samples.

[a03] Audio overlaps for 11ms at playtime 0:00:39. <WARNING>

As you can see the tracks both have the exact same amount of samples and that 3670 samples differs in 5 channels, and that the first difference is found at the same spot that eac3to reports beeing the first overlapping audio, both tracks beeing produced the same way - "on the fly" when demuxing.
Again, if I extract the DTS-HD MA track using eac3to and after that convert to FLAC there is no difference found....

I'm sorry but I cannot provide a sample here, or do not know how as you have to do it on the "fly" when demuxing from a seamless branching blu-ray to reproduce this.

The two lines used for the track:
"C:\Program Files (x86)\eac3to\eac3to.exe" "P:\" 1) 3: "L:\Taken.3.Unrated.FLAC.5.1.24bit.from.DTS-HD.MA.arcsoft.flac" -arcsoft
"C:\Program Files (x86)\eac3to\eac3to.exe" "P:\" 1) 3: "L:\Taken.3.Unrated.FLAC.5.1.24bit.from.DTS-HD.MA.dcadec.flac" -dcadec

And from the eac3to log:
[a03] Decoding with ArcSoft DTS Decoder...
[a03] Decoding with libDcaDec DTS Decoder...

Libeluratio

4th April 2015, 15:37

Nebudchanezzer

4th April 2015, 16:31

Is the flac you get from the demuxed DTS-HD MA track the same as one of the two flac you get from demuxing "on the fly" from your seamless branching blu-ray ? Instead of flac, have you tried to demux to wavs files and compare the results ?

No it ain't, but that is to be expected, du to the nature of beeing forced to keep entire DTS-frames when editing the DTS-stream.

Yes, I have tried to demux to wavs instead of FLAC and it doesn't matter, the difference is still there, when doing it "on the fly".

And using a hex-editor to edit the wav-stream to "correct" the first differences the next differences occur at the time of the next warning of overlapping audio in eac3to.

Libeluratio

4th April 2015, 23:24

Have you tried demuxing the DTS-HD MA track with makemkv/tsmuxer and compare the 3 results ?

Nebudchanezzer

5th April 2015, 07:30

Have you tried demuxing the DTS-HD MA track with makemkv/tsmuxer and compare the 3 results ?

No I haven't since tsMuxer doesn't do flac or wavs or any sort of audio conversion and MakeMKV doesn't do a second pass to fix overlapping audio so that would be pointless as well.

Sparktank

5th April 2015, 08:08

MakeMKV doesn't do a second pass to fix overlapping audio

But it does fix overlapping.
If you check the logs, overlapping on segmented files for playlists does get fixed.

Nebudchanezzer

5th April 2015, 08:18

But it does fix overlapping.
If you check the logs, overlapping on segmented files for playlists does get fixed.

Yes it does but that is the same as eac3to's "[a03] Skipping identical DTS frames (seamless branching)..."

And has very little to with eac3to's second pass where additional overlapping audio is fixed.

EDIT: was wrong about that the editing of DTS-MA-stream does occur in the second pass.

However, just for the sake of it, comparing a FLAC made "on the fly" with a FLAC made from the already extracted DTS MA-stream:

Differences found in compared tracks.
Non-zero offset detected.

Comparing:
"L:\Taken.3.Unrated.FLAC.5.1.24bit.from.DTS-HD.MA.sonic.flac"
"L:\Taken.3.Unrated.FLAC.5.1.24bit.from.extraced.DTS-HD.MA.sonic.flac"
Length mismatch : 1:55:18.503604 vs 1:55:18.506667, 332088173 vs 332088320 samples.
Compared 332088173 samples, discarded last 147 samples from the longer file.
Differences found within the compared range: 1664758852 values, starting at 0:39.455521, peak: 1.4852911 at 1:04:32.798833, 3ch
Detected offset as -185 samples.

Comparing again with corrected offset...
Compared 332087988 samples, with offset of -185 discarding last/first samples from total of 332088173.
Differences found within the compared range: 1560398561 values, starting at 0:01.756146, peak: 1.4692689 at 20:48.833771, 3ch

For some reason dcadec gave an error and would not decode the extracted DTS MA-stream:
The libDcaDec DTS Decoder reported the error "Bitstream navigation error" while decoding. <ERROR>
Aborted at file position 2495873024. <ERROR>

But both arcsoft and sonic decoded the track fine and were bitperfect to each other.

DarkSpace

5th April 2015, 12:22

This sounds like a solution is to join the DTS-HD tracks, decode the joined stream, and only then cut, rather than decoding the streams individually (I remember reading that sometimes the first DTS-HD frame can't be decoded losslessly somewhere on dcadec - link (https://github.com/foo86/dcadec/issues/8#issuecomment-84603411))... not that I actually know what's going on, though, just a guess...

shark75

6th April 2015, 08:35

Thanks for your development and the new eac3to version which supports now Dolby Atmos!

If I extract an Dolby Atmos track I got an audio stream called f.e. Audio_4_English.THD+AC3. If I load this track in mkvmerge they split the Atmos track to two separate tracks:

- TrueHD (ID0, Typ: Audio)
- AC3/EAC3 (ID1, Typ: Audio)

Is this correct? If I playback now the mkv file I have two audio tracks - I think THD is the Dolby Atmos track. Do I need the second (AC3/EAC3) track also in my mkv file or can I deactivate the track before I create my mkv file?

Thanks.

ndjamena

6th April 2015, 09:36

Blu Rays require the inclusion of an AC3 stream within TrueHD for backward compatibility purposes. Eac3to extracts both from an m2ts to a single file. MKVMerge used to take only the TrueHD stream from m2ts/raw TrueHD files but a recently added feature implemented the option of extracting either or both. Unless you have equipment that can't play back the TrueHD track (or any better codec that you could encode it to) the AC3 track is redundant and can be safely removed.

madshi

8th April 2015, 16:07

Nebudchanezzer

8th April 2015, 20:43

Hmmmm... Usually for DTS-HD tracks eac3to reports "skipping identical frames" or something like that, when handling seamless branching titles. And then no 2nd pass is necessary for such tracks. Can you please check if either the old or the new eac3to build (or both) are reporting that? Or do both *not* skip identical frames for this track?

Both eac3to 3.28 and 3.29 does the same in that regards, reports skipping and does a second pass:
eac3to v3.28
command line: "T:\eac3to.3.28\eac3to.exe" "P:\" 1) 3: "L:\Taken.3.Unrated.DTS-HD.MA.5.1.24bit.eac3to.3.28.dtshd"
------------------------------------------------------------------------------
M2TS, 1 video track, 4 audio tracks, 4 subtitle tracks, 1:55:16, 53.548p
1: Chapters, 32 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: DTS Master Audio, English, 5.1 channels, 24 bits, 48kHz
(core: DTS, 5.1 channels, 1509kbps, 48kHz)
4: AC3, English, 5.1 channels, 448kbps, 48kHz
5: AC3, Spanish, 5.1 channels, 448kbps, 48kHz
6: AC3, French, 5.1 channels, 448kbps, 48kHz
7: Subtitle (PGS), English
8: Subtitle (PGS), Spanish
9: Subtitle (PGS), French
10: Subtitle (PGS), English
[a03] Extracting audio track number 3...
[a03] Creating file "L:\Taken.3.Unrated.DTS-HD.MA.5.1.24bit.eac3to.3.28.dtshd"...
[a03] Skipping identical DTS frames (seamless branching)...
[a03] Audio overlaps for 11ms at playtime 0:00:39. <WARNING>
[a03] Audio overlaps for 8ms at playtime 0:04:20. <WARNING>
[a03] Audio overlaps for 12ms at playtime 0:12:44. <WARNING>
[a03] Audio overlaps for 6ms at playtime 0:13:15. <WARNING>
[a03] Audio overlaps for 8ms at playtime 0:17:18. <WARNING>
[a03] Audio overlaps for 11ms at playtime 0:29:06. <WARNING>
[a03] Audio overlaps for 9ms at playtime 0:30:52. <WARNING>
[a03] Audio overlaps for 6ms at playtime 0:33:01. <WARNING>
[a03] Audio overlaps for 5ms at playtime 0:42:04. <WARNING>
[a03] Audio overlaps for 7ms at playtime 0:43:08. <WARNING>
[a03] Audio overlaps for 11ms at playtime 0:47:51. <WARNING>
[a03] Audio overlaps for 12ms at playtime 0:49:17. <WARNING>
[a03] Audio overlaps for 10ms at playtime 0:50:21. <WARNING>
[a03] Audio overlaps for 7ms at playtime 0:51:26. <WARNING>
[a03] Audio overlaps for 12ms at playtime 0:57:15. <WARNING>
[a03] Audio overlaps for 7ms at playtime 1:07:54. <WARNING>
[a03] Audio overlaps for 5ms at playtime 1:13:45. <WARNING>
[a03] Audio overlaps for 8ms at playtime 1:14:42. <WARNING>
[a03] Audio overlaps for 8ms at playtime 1:16:53. <WARNING>
[a03] Audio overlaps for 10ms at playtime 1:22:20. <WARNING>
[a03] Audio overlaps for 10ms at playtime 1:23:27. <WARNING>
[a03] Audio overlaps for 11ms at playtime 1:24:31. <WARNING>
[a03] Audio overlaps for 7ms at playtime 1:29:43. <WARNING>
[a03] Audio overlaps for 8ms at playtime 1:32:04. <WARNING>
[a03] Audio overlaps for 9ms at playtime 1:32:25. <WARNING>
[a03] Audio overlaps for 7ms at playtime 1:34:20. <WARNING>
[a03] Audio overlaps for 9ms at playtime 1:37:09. <WARNING>
[a03] Audio overlaps for 8ms at playtime 1:38:37. <WARNING>
[a03] Audio overlaps for 7ms at playtime 1:39:47. <WARNING>
[a03] Starting 2nd pass...
[a03] Realizing DTS gaps...
[a03] Creating file "L:\Taken.3.Unrated.DTS-HD.MA.5.1.24bit.eac3to.3.28.dtshd"...
Video track 2 contains 165878 frames.
eac3to processing took 6 minutes, 39 seconds.
Done.
eac3to v3.29
command line: "C:\Program Files (x86)\eac3to\eac3to.exe" "P:\" 1) 3: "L:\Taken.3.Unrated.DTS-HD.MA.5.1.24bit.dtshd"
------------------------------------------------------------------------------
M2TS, 1 video track, 4 audio tracks, 4 subtitle tracks, 1:55:16, 53.548p
1: Chapters, 32 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: DTS Master Audio, English, 5.1 channels, 24 bits, 48kHz
(core: DTS, 5.1 channels, 1509kbps, 48kHz)
4: AC3, English, 5.1 channels, 448kbps, 48kHz
5: AC3, Spanish, 5.1 channels, 448kbps, 48kHz
6: AC3, French, 5.1 channels, 448kbps, 48kHz
7: Subtitle (PGS), English
8: Subtitle (PGS), Spanish
9: Subtitle (PGS), French
10: Subtitle (PGS), English
[a03] Extracting audio track number 3...
[a03] Creating file "L:\Taken.3.Unrated.DTS-HD.MA.5.1.24bit.dtshd"...
[a03] Skipping identical DTS frames (seamless branching)...
[a03] Audio overlaps for 11ms at playtime 0:00:39. <WARNING>
[a03] Audio overlaps for 8ms at playtime 0:04:20. <WARNING>
[a03] Audio overlaps for 12ms at playtime 0:12:44. <WARNING>
[a03] Audio overlaps for 6ms at playtime 0:13:15. <WARNING>
[a03] Audio overlaps for 8ms at playtime 0:17:18. <WARNING>
[a03] Audio overlaps for 11ms at playtime 0:29:06. <WARNING>
[a03] Audio overlaps for 9ms at playtime 0:30:52. <WARNING>
[a03] Audio overlaps for 6ms at playtime 0:33:01. <WARNING>
[a03] Audio overlaps for 5ms at playtime 0:42:04. <WARNING>
[a03] Audio overlaps for 7ms at playtime 0:43:08. <WARNING>
[a03] Audio overlaps for 11ms at playtime 0:47:51. <WARNING>
[a03] Audio overlaps for 12ms at playtime 0:49:17. <WARNING>
[a03] Audio overlaps for 10ms at playtime 0:50:21. <WARNING>
[a03] Audio overlaps for 7ms at playtime 0:51:26. <WARNING>
[a03] Audio overlaps for 12ms at playtime 0:57:15. <WARNING>
[a03] Audio overlaps for 7ms at playtime 1:07:54. <WARNING>
[a03] Audio overlaps for 5ms at playtime 1:13:45. <WARNING>
[a03] Audio overlaps for 8ms at playtime 1:14:42. <WARNING>
[a03] Audio overlaps for 8ms at playtime 1:16:53. <WARNING>
[a03] Audio overlaps for 10ms at playtime 1:22:20. <WARNING>
[a03] Audio overlaps for 10ms at playtime 1:23:27. <WARNING>
[a03] Audio overlaps for 11ms at playtime 1:24:31. <WARNING>
[a03] Audio overlaps for 7ms at playtime 1:29:43. <WARNING>
[a03] Audio overlaps for 8ms at playtime 1:32:04. <WARNING>
[a03] Audio overlaps for 9ms at playtime 1:32:25. <WARNING>
[a03] Audio overlaps for 7ms at playtime 1:34:20. <WARNING>
[a03] Audio overlaps for 9ms at playtime 1:37:09. <WARNING>
[a03] Audio overlaps for 8ms at playtime 1:38:37. <WARNING>
[a03] Audio overlaps for 7ms at playtime 1:39:47. <WARNING>
[a03] Starting 2nd pass...
[a03] Realizing DTS gaps...
[a03] Creating file "L:\Taken.3.Unrated.DTS-HD.MA.5.1.24bit.dtshd"...
Video track 2 contains 165878 frames.
eac3to processing took 6 minutes, 55 seconds.
Done.

I'm very curious why eac3to creates different results for the FLAC or WAV(s) depending on wich decoder is used when it comes to seamless branching and overlapping audio.

eac3to "bluray-folder" 1) 3: "audio.flac"

Using a line like that three times, adding either "-dcadec" or "-sonic" creates differences between the results, rather small diffrences but still, diffrences from lossless to lossless.
Take Taken 3 for instance where there is 332088173 samples (332 MILLION) in the FLAC-track, all 3 decoders gives the exact same amount of samples, and between arcsoft and sonic 3650 samples differ, dcadec vs. sonic 3736 differ, dcadec vs. arcsoft 3670 samples differ.

But if you extract the DTS MA track first:

eac3to "bluray-folder" 1) 3: "audio.dtsma"

And then do, using each decoder:

eac3to "audio.dtsma" "audio.flac"

The resulting file is bitidentical (except in the case of Taken 3, dcadec reported an error and exited)

madshi

8th April 2015, 22:20

Nebudchanezzer

8th April 2015, 23:37

It's a bit sad that although identical frames are being skipped, still audio has to be edited with this Blu-Ray. Normally if identical frames are skipped, no further editing is necessary. Can you double check with eac3to 3.27? Both 3.28 and 3.29 are relatively new and have a change in the code which might explain some different behaviour compared to 3.27. So it would be interesting to see how 3.27 behaves in comparison.

3.27 behaves just the same:
eac3to v3.27
command line: "T:\eac3to.3.27\eac3to.exe" "P:\" 1) 3: "L:\Taken.3.Unrated.DTS-HD.MA.5.1.24bit.eac3to.3.27.dtshd"
------------------------------------------------------------------------------
M2TS, 1 video track, 4 audio tracks, 4 subtitle tracks, 1:55:16, 53.548p
1: Chapters, 32 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: DTS Master Audio, English, 5.1 channels, 24 bits, 48kHz
(core: DTS, 5.1 channels, 24 bits, 1509kbps, 48kHz)
4: AC3, English, 5.1 channels, 448kbps, 48kHz
5: AC3, Spanish, 5.1 channels, 448kbps, 48kHz
6: AC3, French, 5.1 channels, 448kbps, 48kHz
7: Subtitle (PGS), English
8: Subtitle (PGS), Spanish
9: Subtitle (PGS), French
10: Subtitle (PGS), English
[a03] Extracting audio track number 3...
[a03] Creating file "L:\Taken.3.Unrated.DTS-HD.MA.5.1.24bit.eac3to.3.27.dtshd"...
[a03] Skipping identical DTS frames (seamless branching)...
[a03] Audio overlaps for 11ms at playtime 0:00:39. <WARNING>
[a03] Audio overlaps for 8ms at playtime 0:04:20. <WARNING>
[a03] Audio overlaps for 12ms at playtime 0:12:44. <WARNING>
[a03] Audio overlaps for 6ms at playtime 0:13:15. <WARNING>
[a03] Audio overlaps for 8ms at playtime 0:17:18. <WARNING>
[a03] Audio overlaps for 11ms at playtime 0:29:06. <WARNING>
[a03] Audio overlaps for 9ms at playtime 0:30:52. <WARNING>
[a03] Audio overlaps for 6ms at playtime 0:33:01. <WARNING>
[a03] Audio overlaps for 5ms at playtime 0:42:04. <WARNING>
[a03] Audio overlaps for 7ms at playtime 0:43:08. <WARNING>
[a03] Audio overlaps for 11ms at playtime 0:47:51. <WARNING>
[a03] Audio overlaps for 12ms at playtime 0:49:17. <WARNING>
[a03] Audio overlaps for 10ms at playtime 0:50:21. <WARNING>
[a03] Audio overlaps for 7ms at playtime 0:51:26. <WARNING>
[a03] Audio overlaps for 12ms at playtime 0:57:15. <WARNING>
[a03] Audio overlaps for 7ms at playtime 1:07:54. <WARNING>
[a03] Audio overlaps for 5ms at playtime 1:13:45. <WARNING>
[a03] Audio overlaps for 8ms at playtime 1:14:42. <WARNING>
[a03] Audio overlaps for 8ms at playtime 1:16:53. <WARNING>
[a03] Audio overlaps for 10ms at playtime 1:22:20. <WARNING>
[a03] Audio overlaps for 10ms at playtime 1:23:27. <WARNING>
[a03] Audio overlaps for 11ms at playtime 1:24:31. <WARNING>
[a03] Audio overlaps for 7ms at playtime 1:29:43. <WARNING>
[a03] Audio overlaps for 8ms at playtime 1:32:04. <WARNING>
[a03] Audio overlaps for 9ms at playtime 1:32:25. <WARNING>
[a03] Audio overlaps for 7ms at playtime 1:34:20. <WARNING>
[a03] Audio overlaps for 9ms at playtime 1:37:09. <WARNING>
[a03] Audio overlaps for 8ms at playtime 1:38:37. <WARNING>
[a03] Audio overlaps for 7ms at playtime 1:39:47. <WARNING>
[a03] Starting 2nd pass...
[a03] Realizing DTS gaps...
[a03] Creating file "L:\Taken.3.Unrated.DTS-HD.MA.5.1.24bit.eac3to.3.27.dtshd"...
Video track 2 contains 165877 frames.
eac3to processing took 6 minutes, 47 seconds.
Done.

If you do "eac3to audio.dtsma audio.flac", does the resulting file match any of the three files you got from "eac3to bluray-folder 1) 3: audio.flac", using those 3 different decoders? Or is it a forth file, different again to the other 3 files?

It is a 4th result, different again from the 3 others, but in my eyes that is to be expected due to the limitations of editing the DTS-stream, the need to insert or remove entire DTS-frames, (512 samples or 10.666..ms of audio), while with RAW audio you could easily add or remove just 1 sample if you wish.

I'm not sure why different decoders produce different results in this situation. Sounds weird. If you can find a way which allows me to reproduce the problem on my PC, I would look into it. But without being able to reproduce the situation, there's probably not much I can do.

Yes, this is a tough nut to crack, for now I can only think of one thing...(must be done via PM I guess), however I'm a bit tired and headed to bed now.

hubblec4

11th April 2015, 10:36

hi madshi

is a support for DTS Express planed?

OK that was a little bit wrong for understanding...
I mean the demux option with the switch "-demux".

mmg supports now the dts-express track.
and when you support the demux which extension is used?

(like dtsma or dtshr) maybe dtsex?

Q-the-STORM

11th April 2015, 15:23

as long as you're on a roll with improving eac3to, maybe you can dump aften and encode ac3 with libav?

One dts-hd ma source decoded with eac3to
Two ac3 encodes of the decoded source (both 448kbps), one encoded with eac3to (aften), the other with ffmpeg (libav)

http://justpic.info/images1/567f/NPpb1.jpg
http://justpic.info/images1/af48/ixnxz.jpg

as you can see spectral frequency display shows that aften has cutoff at about 16,5kHz while ffmpeg has it at about 21kHz
(I only had the center in that screenshot, but it applies to all channels...)

that's a lot of lost information...

Motenai Yoda

11th April 2015, 19:16

I don't think the lowpass frequency is a good point of comparison.

soneca

13th April 2015, 00:43

I don't think the lowpass frequency is a good point of comparison.

It may not even be in terms of comparison but if that loss actually happens considering a conversion starting from a source without loss into the ac3 with decent bitrate I guess I should not be this cut in just 16,5Khz.

Motenai Yoda

13th April 2015, 16:02

It may not even be in terms of comparison but if that loss actually happens considering a conversion starting from a source without loss into the ac3 with decent bitrate I guess I should not be this cut in just 16,5Khz.

Yep but ac3 is a quite old codec and not well tuned for >96kbps/ch encodings, and you should consider that throwing away very high frequencies (mainly just noise and dither), it's able to raise the quality of super-wideband ones.
Almost all lossy codecs apply a low-pass filter

Atak_Snajpera

13th April 2015, 17:32

Exactly Motenai Yoda. It is better to have more bits in areas where you actually can here difference than waste bitrate for high frequencies where most adults (30+) do not here anything. After all it is a lossy codec. Some information must be discarded.

Q-the-STORM

13th April 2015, 20:15

all true.... but the aften encode does sound worse (I let a few people do double blind tests, though that's not really enough to draw a real conclusion)... and the official dolby encoder does not cut off at 16,5Hz... even aften's developer says that nobody should be using aften anymore and everyone should switch to libav....

DoctorM

13th April 2015, 20:46

Q-the-STORM

13th April 2015, 21:07

Got a link for that quote?

these are from mid 2011
Well, yeah it's pretty much abandoned. At least I'm not planning on spending my time improving it. It still does have multi-threaded encoding, which the Libav encoder does not have, but in pretty much every other way the Libav encoder is better.

I don't really have time for a release right now. I'm very busy improving the (E-)AC3 encoder in Libav. It's better than Aften now, and I will most likely no longer do additional improvements to Aften other than bug fixes.

from his github page

I am currently working on improving the (E-)AC-3 encoder. The improvements were based initially on my previous work with the Aften project, but at this point the Libav encoder is more advanced.

LigH

14th April 2015, 08:23

I faintly remember how Aften developers wondered about improving the quality by learning from LAME. But if libav already surpasses Aften, well ... it's getting more interesting.

Furiousflea

14th April 2015, 20:51

Hi there, brilliant developments with the new open dcadec stuff.
I'm currently swapping out for the opus codec, seems to produce fantastic results.

Anyways,

I've noticed that eac3to isn't always automatically selecting the dcadec decoder by default for 7.x tracks as it should, currently on "Dawn Of The Planet Of The Apes", the 7.1 "strange setup" is still decoding with arcsoft...I've set the swtich to force dcadec decoder, but am a little confused as to if this is correct or that maybe there is a reason for this still going the old arcsoft route by default?

Thanks :)
Great work, didn't think .29 would ever be released but mighty pleased it's here.

Motenai Yoda

15th April 2015, 00:19

I'm currently swapping out for the opus codec, seems to produce fantastic results.
[OT MODE on]
Be aware that opus encode only at those samplerate

+----------------------+-----------------+-------------------------+
| Abbreviation | Audio Bandwidth | Sample Rate (Effective) |
+----------------------+-----------------+-------------------------+
| NB (narrowband) | 4 kHz | 8 kHz |
| | | |
| MB (medium-band) | 6 kHz | 12 kHz |
| | | |
| WB (wideband) | 8 kHz | 16 kHz |
| | | |
| SWB (super-wideband) | 12 kHz | 24 kHz |
| | | |
| FB (fullband) | 20 kHz (*) | 48 kHz |
+----------------------+-----------------+-------------------------+
(*) Although the sampling theorem allows a bandwidth as large as half
the sampling rate, Opus never codes audio above 20 kHz, as that is
the generally accepted upper limit of human hearing.

If input samplerate didn't match opus use the silk resampler.
[OT MODE off]

Furiousflea

15th April 2015, 00:57

[OT MODE on]
Be aware that opus encode only at those samplerate

+----------------------+-----------------+-------------------------+
| Abbreviation | Audio Bandwidth | Sample Rate (Effective) |
+----------------------+-----------------+-------------------------+
| NB (narrowband) | 4 kHz | 8 kHz |
| | | |
| MB (medium-band) | 6 kHz | 12 kHz |
| | | |
| WB (wideband) | 8 kHz | 16 kHz |
| | | |
| SWB (super-wideband) | 12 kHz | 24 kHz |
| | | |
| FB (fullband) | 20 kHz (*) | 48 kHz |
+----------------------+-----------------+-------------------------+
(*) Although the sampling theorem allows a bandwidth as large as half
the sampling rate, Opus never codes audio above 20 kHz, as that is
the generally accepted upper limit of human hearing.

If input samplerate didn't match opus use the silk resampler.
[OT MODE off]

Thanks for taking the time to post, it's ok though I read up fully and was aware of this so am only using it with 48Khz sample rate tracks, which is 96-97% of my material. Really appreciate that there's people like yourself willing to take the time to point this out as it could have been a disaster had I not know.

Can't fault this opus codec, quality is simply astonishingly good, only time it needs a little helping hand is for extremely busy audio tracks and it's quite obvious as the average is near the vbr average very quickly in those instances...anyway back on topic...

Nebudchanezzer

15th April 2015, 05:24

I've noticed that eac3to isn't always automatically selecting the dcadec decoder by default for 7.x tracks as it should, currently on "Dawn Of The Planet Of The Apes", the 7.1 "strange setup" is still decoding with arcsoft...I've set the swtich to force dcadec decoder, but am a little confused as to if this is correct or that maybe there is a reason for this still going the old arcsoft route by default?

The developer is aware of this behaviour, and it is not supposed to be this way, should be fixed in a new version.

Furiousflea

15th April 2015, 08:32

The developer is aware of this behaviour, and it is not supposed to be this way, should be fixed in a new version.

Good news and reassuring, thanks for your time.

tebasuna51

19th April 2015, 12:55

I'm not sure why different decoders produce different results in this situation. Sounds weird. If you can find a way which allows me to reproduce the problem on my PC, I would look into it. But without being able to reproduce the situation, there's probably not much I can do.

I make a check about one overlap in Taken 3 BD. This one:
[a03] Audio overlaps for 12ms at playtime 0:12:44

BDInfo Name Time In Length
----------- ------- ------
...
02269.M2TS 0:10:47.188 0:01:56.407
02318.M2TS 0:12:43.596 0:00:31.364
...

1) Decode to wavs the full DTS-HD MA track using ArcSoft and DcaDec.
There are low differences (-84.29 dB) in C channel and time 0:12:43.57729 (47 samples between 0:12:43.577146 and 0:12:43.578125).
I call the full C channel wav like GAPS.wav

2) Decode to wav the dts's extracted and joined from 02269.M2TS and 02318.M2TS.
I call the C channel wav like NO_GAPS.wav.

3) I compared the GAPS.wav and NO_GAPS.wav. See the attached image from NO_GAPS.wav and:

- There are 587 samples less (12.2 ms) in GAPS.wav (at 0:12:43.578). B zone.

- There are 47 samples different (A zone at 0:12:43.577). Seems a interpolation to avoid a click in join point.

- The point when finish the 02269.dts match with the BDInfo cut point 0:12:43.596 (after than 0:12:43.577)

- The first 256 samples from 02318.dts (C zone) exist in GAPS.wav, but maybe are wrong because we can't know if last frame from 02269.dts is the correct one to initialize the first 02318.dts frame.

Conclusions:

a) I don't know for wath the point selected to realize the gap (cut 12 ms) is 0:12:43.577-8, seems more convenient 0:12:43.596 to cut possible wrong samples instead correct samples.
In this case the correct point match with BDInfo but I can't be sure if is always true.

b) I don't know for what the differences between ArcSoft and DcaEnc decode, but zone A is irrelevant at all, maybe rounded differences in interpolation.

c) The more important conclusion:

When we have a "seamless branching" BD and the "skipping identical frames" method is not enough to recover the sync video-audio, and the "Realizing DTS gaps..." is necesary, we can't recover a bitidentical lossless source.
See http://forum.doom9.org/showthread.php?p=1600694#post1600694 for more info.

The join points always are innacurate.

Smithy

20th April 2015, 19:38

as long as you're on a roll with improving eac3to, maybe you can dump aften and encode ac3 with libav?

One dts-hd ma source decoded with eac3to
Two ac3 encodes of the decoded source (both 448kbps), one encoded with eac3to (aften), the other with ffmpeg (libav)

as you can see spectral frequency display shows that aften has cutoff at about 16,5kHz while ffmpeg has it at about 21kHz
(I only had the center in that screenshot, but it applies to all channels...)

that's a lot of lost information...

this must be wrong bandwidth setting by eac3to @ encoding 5.1 448 or 384 kbps.

aftengui or wavtoac3encoder have Bandwidth settings:

the best audio quality is set bandwidth to close by/above the Source frequency are.
it makes no sense to use more bandwidth setting then Source have, to save more Audio Quality and Bitrate for the Real Frequency.

AC3 5.1 @ 448 kbps need a bandwidth of 48 for frequency around 20 kHz (official dolby encoder)
AC3 5.1 @ 384 kbps need a bandwidth of 40 for frequency around 18 kHz (official dolby encoder)

Max. Bandwidth is 60 @ frequency around 24 kHz when is needed for 5.1 @ 640kbps and it works fine in eac3to.
so eac3to use bandwidth around ~30 for 448 and ~20 for 384, and thats killed all frequency above 16,5 kHz (448) and 14,3 kHz (384)

AftenGui ist the better and much faster way for AC3 encoding then eac3to. (i don't know how much fast ffmpeg is)
Surcode for Dolby Digital have a DC-Offset Filter during the compression @ Encoding, but encoding is very slow, no bandwidth option and a cutoff by 20,34 kHz.
madshi is that possible u can add a DC-Offset Filter and Dialog normalisation (-27db) for AC3 encoding in eac3to, maybe in future ?
an LFE lowpass (120hz) Filter is welcome, too. ;)

http://abload.de/img/aftenguibandwidthimuwx.png

DoctorM

20th April 2015, 23:43

Smithy

21st April 2015, 07:02

My old 'Soft Encode' software is supposed to be an official DD encoder and it largely agrees: for 5.1 channels @ 384kbps = 18.05khz, but 448-640kbps = 20.30khz. Nothing makes the audio bandwidth go higher than that. Maybe an EX extension is needed (which Soft Encode doesn't support.)

Also, it recommends you always enable the DC high-pass filter, the Bandwidth low-pass filter and the LFE low-pass filter for best results.

not Allways, these Filters are recommended for lower bitrate to save more Quailty.

So if necessary then use the High-pass or Bandwidth low-pass Filter, but this cut-off frequency, too

LFE Lowpass Filter is only set for High frequency above 120 Hz, so when the Soure was filtered, u don't need lfe low-pass filter again.

The EX extension set only a Flag Matrix for 6.1/7.1 Audio, so the Bandwidth are the same.

EDIT:
many Master Tracks (DTS-HD MA, TrueHD or PCM) have DC offset and many of them are normalized to 0.0 dB .
The First Step bevor AC3 Encoding is:
Fix DC-Offset and Normalize the Complete AudioMix maybe to -2dB/-3dB for safty against Clipping an more DC-Offset from Compression @ AC3 Encode (normalize can be differently from Mix to Mix and wich Bitrate is used)

tebasuna51

22nd April 2015, 19:46

... even aften's developer says that nobody should be using aften anymore and everyone should switch to libav....

You are free to use external encoders with eac3to, for instance:

eac3to input stdout.w64 | ffmpeg -i - -c:a ac3 -b:a 640k output.ac3

DoctorM

22nd April 2015, 19:47

From Dolby's website:
DC Filter
This parameter determines whether a DC-blocking 3 Hz highpass filter is applied to the main input channels of a Dolby Digital encoder prior to encoding. This parameter is not carried to the consumer decoder. It is used to remove DC offsets in the program audio and would only be switched off in exceptional circumstances.

Lowpass Filter
This parameter determines whether a lowpass filter is applied to the main input channels of a Dolby Digital encoder prior to encoding. This filter removes high-frequency signals that are not encoded. At the suitable data rates, this filter operates above 20 kHz. In all cases it prevents aliasing on decoding and is normally switched on. This parameter is not passed to the consumer decoder.

LFE Lowpass Filter
This parameter determines whether a 120 Hz eighth-order lowpass filter is applied to the LFE channel input of a Dolby Digital encoder prior to encoding. It is ignored if the LFE channel is disabled. This parameter is not sent to the consumer decoder. The filter removes frequencies above 120 Hz that would cause aliasing when decoded. This filter should only be switched off if the audio to be encoded is known to have no signal above 120 Hz.

'Exceptional circumstances' sure doesn't sound like 'only for low bitrate'. The lowpass filter also seems to alter its cutoff with bitrate from the way it is described.

IIRC, the only times you should disable these is if you know you've already filtered these frequencies from your audio track.
Why would you want to waste bitrate on frequencies that cannot be heard? That just makes audible frequencies worse.

arrgh

22nd April 2015, 19:49

ability to analyse and extract iso files (without mounting them) would be a nice feature for batch conversions with eac3to...

Q-the-STORM

23rd April 2015, 07:22

You are free to use external encoders with eac3to, for instance:

eac3to input stdout.w64 | ffmpeg -i - -c:a ac3 -b:a 640k output.ac3

that's what I'm doing atm...

huhn

24th April 2015, 22:32

ability to analyse and extract iso files (without mounting them) would be a nice feature for batch conversions with eac3to...

windows 10 can mount isos natively. this may helps adding things like that.

nevcairiel

24th April 2015, 23:32

windows 10 can mount isos natively. this may helps adding things like that.

This is not new in 10, 8.1 can also do that.

LigH

25th April 2015, 15:04

And in other versions one may use any "virtual CDVD driver" (like Daemon Tools); but it doesn't matter: The question was if it would be possible to handle in eac3to only, without mounting to a drive letter. That may be similar to handling any (possibly uncompressed) archive format like ZIP, RAR, TAR like a virtual directory. Already sounds like heavy duty. I wouldn't be surprised if nev replied, that would not be the purpose of eac3to...

arrgh

25th April 2015, 16:41

... I wouldn't be surprised if nev replied, that would not be the purpose of eac3to...

probably a lot of work...
I was mentioning it, because MakeMKV can do this...but it muxes directly in to a mkv without the option to do something inbetween, like converting to aac or other things...

ndjamena

25th April 2015, 18:57

probably a lot of work...
I was mentioning it, because MakeMKV can do this...but it muxes directly in to a mkv without the option to do something inbetween, like converting to aac or other things...

MakeMKV CAN convert any DVD or Blu Ray compliant audio to aac, ac3 or FLAC while remuxing from DVDs, Blu Rays or an MKV to MKV...

You just need to learn to use profiles properly.

arrgh

25th April 2015, 23:50

...
You just need to learn to use profiles properly.

exactly....which is not straight forward...and if you want to slow down, normalize, add an empty subtitle stream, if needed, than it is still necessary (or at least easier) to demux make the changes and remux again...

Xor

27th April 2015, 00:13

Please help me, ho to force eac3to to convert to custom fps range?

Example:

C:\eac3to327>eac3to.exe "AUDIO-ENG.ac3" "AUDIO-ENG-24917.ac3" -23.976 -changeTo24.917
FPS value "24.917" not supported.

Or alternative tools to convert to "custom fps" ???

Thanks

LigH

27th April 2015, 07:22

If you have to use such strange relations, you shall better wonder why. No professional video studio should use a workflow which results in such nonsense. Are you trying to mix video and audio from different productions, possibly even with different cuts?

Music Fan

27th April 2015, 08:42

Or alternative tools to convert to "custom fps" ???
Hybrid (which uses Sox for audio changes) ;
http://forum.doom9.org/showthread.php?t=153035
You have the choice between fps and duration (specify original and destination) and you can change the pitch or not, very convenient.

hubblec4

27th April 2015, 10:56

Hi madshi

I have a BD - The Expendables 3 which have a mpls that plays two m2ts files.
The first m2ts file has different audio settings as the second one.

mmg abort with an error message at muxing.
eac3to seems to decode the audio as well but im not sure.

here the logs and a link to a test BD (http://forum.videohelp.com/attachments/31440-1430126678/The%20Expendables%203%20-%20BD_test.7z): first m2ts(0001) is cutted with DGSplit after 15mb, the second m2ts(0002) is untouched (other m2ts files are removed)

log-0001.mpls
eac3to v3.29
command line: eac3to "E:\Videobearbeitung\The Expendables 3\The Expendables 3 - BD_test\BDMV\PLAYLIST\00001.mpls" 1) -log="E:\Videobearbeitung\The Expendables 3\log.txt"
------------------------------------------------------------------------------
M2TS, 1 video track, 2 audio tracks, 4 subtitle tracks, 0:00:12, 0.059p
1: Chapters, 12 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: TrueHD/AC3, German, 5.1 channels, 48kHz
(embedded: AC3, 5.1 channels, 448kbps, 48kHz)
4: TrueHD/AC3, English, 5.1 channels, 48kHz
(embedded: AC3, 5.1 channels, 640kbps, 48kHz)
5: Subtitle (PGS), German
6: Subtitle (PGS), German
7: Subtitle (PGS), German
8: Subtitle (PGS), English

log-only-0001.m2ts
eac3to v3.29
command line: eac3to "E:\Videobearbeitung\The Expendables 3\The Expendables 3 - BD_test\BDMV\STREAM\00001.m2ts" -log="E:\Videobearbeitung\The Expendables 3\log.txt"
------------------------------------------------------------------------------
M2TS, 1 video track, 2 audio tracks, 4 subtitle tracks, 0:00:06, 24p /1.001
1: h264/AVC, 1080p24 /1.001 (16:9)
2: TrueHD/AC3 (Atmos), German, 7.1 channels, 48kHz
(embedded: AC3 EX, 5.1 channels, 448kbps, 48kHz)
3: TrueHD/AC3 (Atmos), English, 7.1 channels, 48kHz
(embedded: AC3, 5.1 channels, 640kbps, 48kHz)
4: Subtitle (PGS), German
5: Subtitle (PGS), German
6: Subtitle (PGS), German
7: Subtitle (PGS), English

log-Flac-encode
eac3to v3.29
command line: eac3to "E:\Videobearbeitung\The Expendables 3\The Expendables 3 - BD_test\BDMV\PLAYLIST\00001.mpls" 1) 3: eng.flac -log="E:\Videobearbeitung\The Expendables 3\log.txt"
------------------------------------------------------------------------------
M2TS, 1 video track, 2 audio tracks, 4 subtitle tracks, 0:00:12, 0.059p
1: Chapters, 12 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: TrueHD/AC3, German, 5.1 channels, 48kHz
(embedded: AC3, 5.1 channels, 448kbps, 48kHz)
4: TrueHD/AC3, English, 5.1 channels, 48kHz
(embedded: AC3, 5.1 channels, 640kbps, 48kHz)
5: Subtitle (PGS), German
6: Subtitle (PGS), German
7: Subtitle (PGS), German
8: Subtitle (PGS), English
[a03] thd, 48000, 5.1
[a03] Extracting audio track number 3...
[a03] Extracting TrueHD stream...
[a03] Decoding with libav/ffmpeg...
[a03] Encoding FLAC with libFlac...
[a03] [libav] Unknown channel layout. <WARNING>
[a03] [libav] If you want to help, upload a sample of this file to ftp://upload.ffmpeg.org/MPlayer/incoming/ and contact the ffmpeg-devel mailing list. <WARNING>
[a03] Creating file "eng.flac"...
[a03] The original audio track has a constant bit depth of 21 bits.
Video track 2 contains 287 frames.
eac3to processing took 1 second.
Done.

tebasuna51

27th April 2015, 12:06

eac3to seems to decode the audio as well but im not sure.
...
[a03] [libav] Unknown channel layout. <WARNING>

The output is wrong, begin with 6 channels but in next m2ts there are 8 channels and the audio data is missinterpreted still like 6 channel.

See the durations:
00002.m2ts -> 6s (6.006)
00001.m2ts -> 6s (5.964)
00001.mpls -> 12s (11.970)
eng.flac -> 13.133s

ndjamena

27th April 2015, 17:26

When I transcode audio to FLAC with MakeMKV and look at the track using MediaInfo I get info about the Channel Positions in the output. If I re-encode the same audio in using EAC3To and look at THAT with MediaInfo the Channel Position Data is missing. Is this a problem with Eac3to, is MediaInfo failing to display some default values or has it been decided that adding whatever headers that info is stored in isn't worth the effort?

(Should I be adding the default values myself? What are the defaults for each and every channel count?)

Channel positions : Front: L C R, Side: L R, Back: L R, LFE

tebasuna51

27th April 2015, 20:03

When I transcode audio to FLAC...
What are the defaults for each and every channel count?

http://forum.doom9.org/showthread.php?p=1718489#post1718489

Xor

27th April 2015, 21:01

Hybrid (which uses Sox for audio changes) ;
http://forum.doom9.org/showthread.php?t=153035
You have the choice between fps and duration (specify original and destination) and you can change the pitch or not, very convenient.

Thanks

Furiousflea

28th April 2015, 04:33

http://forum.doom9.org/showthread.php?p=1718489#post1718489

Interesting you post this.

Does eac3to apply a custom channel mask automatically if say encoding 3/1 (4 channel track with 3 channels at the front, 1 at the rear)

I ask because eac3to detects the track correctly and states "3/1" before demuxing, but when encoding mediainfo reports left/right/rear left/rear right...

...Or is end user expected to input mask regardless?

Thanks, I know this kind of thing has been mentioned countless times before, but it never seems to get answered with any certainty.

ndjamena

28th April 2015, 09:57

http://forum.doom9.org/showthread.php?p=1718489#post1718489

OK, I guess that leaves the question: What is MakeMKV doing differently that the Channel Layout is shown by MediaInfo... And how can I add that info to an eac3to FLAC encode after encoding?

tebasuna51

28th April 2015, 11:15

I ask because eac3to detects the track correctly and states "3/1" before demuxing, but when encoding mediainfo reports left/right/rear left/rear right....

And how can I add that info to an eac3to FLAC encode after encoding?

Same answer for both: eac3to work fine, maybe MediaInfo is not perfect.

eac3to v3.29 command line: eac3to 4w310.wav 4w310.flac
------------------------------------------------------
WAV, 3/1 channels, 0:00:20, 16 bits, 3072kbps, 48kHz
Reading WAV...
Creating file "D:\tmp\4w310.flac"...

eac3to v3.29 command line: eac3to 4w310.flac
------------------------------------------------------
FLAC, 3/1 channels, 0:00:20, 16 bits, 202kbps, 48kHz

Flac identified correctly and played fine by MPC-HC like FL FR FC BC.
MediaInfo don't say nothing about Channel Layout.

eac3to v3.29 command line: eac3to 4w220.wav 4w220.flac
------------------------------------------------------
WAV, 2/2 channels, 0:00:20, 16 bits, 3072kbps, 48kHz
Reading WAV...
Creating file "D:\tmp\4w220.flac"...

eac3to v3.29 command line: eac3to 4w220.flac
------------------------------------------------------
FLAC, 2/2 channels, 0:00:20, 16 bits, 205kbps, 48kHz

Flac identified correctly and played fine by MPC-HC like FL FR SL SR.
MediaInfo don't say nothing about Channel Layout.

ndjamena

28th April 2015, 13:42

-Edit- Nevermind, Visual Studio seems to accept 0X as a hex prefix...

Um, I've only ever seen 0x used as a Hex prefix, does anyone know who sets the standards and whether the case of the 'x/X' is supposed to matter? ie 0x vs. 0X

ndjamena

28th April 2015, 14:45

Fixed :)

http://forum.doom9.org/showpost.php?p=1719488&postcount=1376

(For one program at least.)

tebasuna51

28th April 2015, 17:37

Off topic Xor post moved to http://forum.doom9.org/showthread.php?t=172085

Furiousflea

29th April 2015, 23:28

Thanks tebasuna51 for clearing that niggling doubt up once and for all, much appreciated :)

Atak_Snajpera

30th April 2015, 13:57

Is it possible to decode only specific channel with eac3to? I've checked this site http://en.wikibooks.org/wiki/Eac3to/How_to_Use and haven't found anything.

tebasuna51

30th April 2015, 14:39

You can decode to multiple wavs, not only one channel:
output.file ~ This is the output file that eac3to will create. It could be an audio format like RAW, (L)PCM, WAV (PCM only), WAVs (multiple mono WAV files, PCM only),...

eac3to input output.wavs

Atak_Snajpera

30th April 2015, 15:18

But what if I want to pipe just one channel?

something like this
eac3to.exe some.flac stdout.wav -channel 0 | lossywav.exe | flac.exe

tebasuna51

30th April 2015, 17:19

It's not possible, there are the remap parameter -0,4,5,1,2,3 but is ignored when there are less channels than input.

Maybe you can filter the channels with sox.

nautilus7

1st May 2015, 20:01

You can decode/save only center channel using "-mono" and ".wavs" as output format.

ndjamena

4th May 2015, 01:33

Another FLAC file MediaInfo can't detect the channel layout of.

This one doesn't seem to have that Layout MetaData Tag in it though, which I assume means it "defaults" to what's on that table.

It's source is 5.1 True HD with a layout of - Front: L C R, Side: L R, LFE - which would make it 5.1(side) yet unless I'm reading it wrong the table indicates 6 channels should be 5.1(back)

https://xiph.org/flac/format.html#def_STREAMINFO

◦6 channels: front left, front right, front centre, LFE, back/surround left, back/surround right

FFMPEG is detecting it as 5.1(side), are they the same thing? The terminology is confusing. What am I missing?

ndjamena

4th May 2015, 09:42

Anyway, I grabbed the 5.1(side) layout Hex Value from a MakeMKV encode (0x60F), and used MP3Tag to add the WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag to the file in the abundance of space EAC3To leaves in it's forward headers.

Now I finally have a copy of The Matrix with it's actual 16 bit audio while still displaying channel layout in MediaInfo. Reloaded and Revolutions are next, then when MakeMKV fixes its surround sound FLAC decoding I'll remux the MKV while re-encoding the FLAC and no one will ever know it wasn't encoded straight from the original 24 bit TrueHD track.

I'm going to have to go back and fix all the other FLAC tracks I did with EAC3To eventually...

madshi

4th May 2015, 10:15

There is nothing to "fix" in eac3to created FLAC files. eac3to automatically writes the WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag when it's needed, and doesn't write it when it's not needed. The tag is not needed when the channel mask matches the FLAC default channel mask. As far as I can see, any software which doesn't handle the channel mask of eac3to created FLAC files correctly has to be considered buggy.

ndjamena

4th May 2015, 10:40

madshi

4th May 2015, 11:03

There has been a history of confusion with 5.1 channel assignments. In theory there's a difference between 5.1(back) and 5.1(side), but in real life there really isn't. Old Windows versions used channelmask 0x3F, which is 5.1(back), newer versions are using 0x60F, which is 5.1(side). Practically, when transporting this kind of data as 5.1 via HDMI to the receiver, it ends up all the same. The FLAC spec says that the default channel order for 5.1 is "5.1(back/side)". Well, it's described in other words, but you get my meaning: The FLAC spec doesn't make a difference between side and back for 5.1 channels. And neither does eac3to. The correct format is 5.1(side). And the only proper way to handle 5.1(back) is to treat it as 5.1(side), as well.

I don't know what problem MediaInfo might have, I don't use it. Fact is, if WAVEFORMATEXTENSIBLE_CHANNEL_MASK is specified, that's the channel assignment you should use. If that WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag is missing, then the default FLAC channel assignment should be used. On the following page search for "6 channels:" to see a list of the FLAC default channel assignments:

https://xiph.org/flac/format.html

tebasuna51

4th May 2015, 11:40

The fisrt M$ spec about 5.1 was FL,FR,FC,LF,BL,BR (back, mask 0x003F) and match the AC3 5.1 layout L,C,R,SurroundL,SurroundR,LFE or the DTS layout C,L,R,Ls,Rs,LFE

When come the 7.1 channels FL,FR,FC,LF,BL,BR,SL,SR (back, side, mask 0x063F) the M$ 5.1 specs change (if I remember whit M$ XP) to prefer FL,FR,FC,LF,SL,SR (side, mask 0x060F) over the old FL,FR,FC,LF,BL,BR but both specs remain valid, for backward compatibility, and any players must play the same with mask 0x003F or 0x060F.

Then, in a 5.1 layout, the last channels can be named Back, Side or simple Surround at your choice. That means the FLAC back/surround channels.

Only the 6.1 layout can be problematic because in the old M$ style FL,FR,FC,LF,BL,BR,BC (0x013F) the last channels don't have the same order than the new FL,FR,FC,LF,BC,SL,SR (0x070F), then here is important the correct channel-mask and order.
Any updated soft, like eac3to, must use FL,FR,FC,LF,BC,SL,SR (0x070F) and here FLAC is clear:
7 channels: front left, front right, front center, LFE, back center, side left, side right

EDIT: I don't see the madshi reply

torturesauce

8th May 2015, 04:03

nevcairiel

8th May 2015, 09:00

tebasuna51

8th May 2015, 12:28

dcadec still cannot play 20-bit DTS files (frequently found on DTS-CD's), and whenever I play them in foobar, they sound garbled and sped-up. Arcsoft is still the solution; it patches the bitdepth to 24 bits and converts the file to WAV/FLAC so you can listen to it with foobar. Just thought I should point this out.

Don't exist such "20-bit DTS files" and ArcSoft can't "patches the bitdepth to 24 bits" because a standard DTS don't have bitdepth.

Seems you mistake a DTSWAV from a DTS-CD with that.

A DTSWAV have a fake WAV header like a PCM stereo 16 bits 44100 samplerate to be accepted to burn a CD, but the data is a special DTS stream 5.1.

Is special because the 2 most significant bits of each WORD (16 bits) are set to '0', to avoid speakers damage in players than not recognize this format and try to play this WAV like a standard WAV PCM.

The WORD's in the special DTS data in the stream use only 14 bits Little-Endian and not 16 bits Big-Endian like a standard DTS.

You can create a DTSWAV from 6 source mono WAV's PCM 44100 Hz with DTS Master Audio.

Also with a source 5.1 WAV PCM 44100 Hz and ffdcaenc:
ffdcaenc -e -r -i source.wav -o output.dts -b 1411.2

you can create the DTS 14 bits Little-Endian, and to obtain the DTSWAV:
wavfix output.dts DTSWAV.wav -s 44100

Here is a Channel test sample: https://www.sendspace.com/file/dws3gx

EDIT:
To convert a DTSWAV.WAV to a standard DTS 16 bits Big-Endian you can use the old BeSplit:
BeSplit -core( -input "DTSWAV.wav" -prefix "x" -type dtswav -fix )

Thunderbolt8

8th May 2015, 15:09

but 20-bit DTS-HD MA tracks are decoded perfectly with dcadec? (those 24-bit tracks which only have 20-bit of real data and the rest is empty)

nevcairiel

8th May 2015, 15:19

They should be fine. If you have anything that doesn't decode properly, just report them, and it'll get fixed. If you just assume its broken for some reason and never give us or the developer of dcadec a chance to check it out (say, by providing a sample), its not going to get any better either.

Furiousflea

9th May 2015, 19:13

Yes, MediaInfo IS buggy, I don't need to be told that. However, my batches and a lot of other programs use it and so far every EAC3To encode has buggered up my audio naming scripts.

I don't know what to tell Jerome and so far no one has told me what's going on, he does expect me to know something about the bug I'm reporting, or at least someone too.

Tebasuna51's link and the FLAC webpage seem to be saying the default is 5.1(back) not 5.1(side), is there another way of stating layout somewhere that I'm missing? Tell me what I need to know and I'll tell Jerome otherwise I'll fix it however I can until a better way comes along.

(MediaInfo may not be the only program with this problem, so it can't hurt to mention the solution, although a world where every program was perfect would be nice.)

Mediainfo isn't buggy.
Media info is technically correct. It's a software to tell you specification of a file, that's what it's supposed to do. The issue isn't with Mediainfo.
eac3to is practically correct and technically wrong, but only by definition, not in any actual usage scenario.
So all are correct, none are buggy.

The "issue" is one of definition, a definition that is never practically exploited and an uncorractable legacy without new standards.
Why would new standards be created to "fix" a legacy issue that has no practical downside? :)

FLAC spec can't hold side/back channel info, it's all "back".
No player plays "back" as "back" unless there is a "side".
If there is a "side" then "back" will be correct, if there isn't, it will still be correct becasuse it will be played as side.

...Blame Dolby if anyone and their stupid 90s marketing where they insisted side=back.

ndjamena

9th May 2015, 19:26

Um, MediaInfo reports NO Layout if it's not specifically mentioned in a WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag, which is apparently not how the FLAC specifications work. That's a bug.

The whole 5.1 side/back thing was just me trying to clarify how it's supposed to work so I could properly report it...

http://forum.doom9.org/showthread.php?p=1718489#post1718489

Tebasuna51 seems to like using the old 5.1(back) numbers (0x003F), whereas there's a new number for 5.1(side) (0x60F). Add to that the ambiguity of the FLAC naming ( back/surround left, back/surround right) and I was confused.

tebasuna51

10th May 2015, 11:19

...
Tebasuna51 seems to like using the old 5.1(back) numbers (0x003F), whereas there's a new number for 5.1(side) (0x60F). Add to that the ambiguity of the FLAC naming ( back/surround left, back/surround right) and I was confused.

Read also my post http://forum.doom9.org/showthread.php?p=1720161#post1720161
"... the M$ 5.1 specs change (if I remember whit M$ XP) to prefer FL,FR,FC,LF,SL,SR (side, mask 0x060F) over the old FL,FR,FC,LF,BL,BR but both specs remain valid, for backward compatibility, and any players must play the same with mask 0x003F or 0x060F."

The Surround channels in AC3 or DTS 5.1 are at +-120º from front, the Side channels in WAV are at 90º-110º and Back at 130º-150º, none are exact and both can be used, don't make a problem with this.

ndjamena

10th May 2015, 12:26

MediaInfos bug relating to the reading of hex values with uppercase 'X's in the WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag has already been fixed and will be included in the next release.

MediaInfos bug in relation to default channel mapping in FLAC has been acknowledged and will most likely be fixed in the next release as well.

At that point MediaInfo and EAC3To will be fully cross compatible in regards to FLAC channel layouts, and you'll never hear about it again.

tebasuna51

10th May 2015, 23:09

@jriker1
What is your question?

Now the libDcaDec is the default DTS 7.1 decoder, your log is ok.

r0lZ

12th May 2015, 09:55

I have read this in an old post from October 2008:
NOTE:Some Blu-ray disks which have playlists containing multiple m2ts files carry audio ovarlaps/gaps.
If this audio file is a TrueHD, this can't be corrected by eac3to. In this case truehd must be converted to pcm or flac.
Is it still true, or is eac3to able to process the overlaps in BD THD+AC3 streams correctly now?

I wonder also if tsMuxeR has the same problem when it demuxes the THD track from a multi-M2TS playlist?
In the tsMuxeR log, I see messages like this one:

TRUE-HD stream (track 3): overlapped frame detected at position 00:04:15,391. Remove frame.

It seems therefore that tsMuxeR can remove the overlaps, but I note that the message is printed only once, and I don't know if it refers to the THD or the AC3 core, or both.

And can I assume that the overlaps are removed properly by the two programs if only the 5.1 AC3 core is extracted from the THD+AC3 BD stream?

tebasuna51

18th May 2015, 13:43

stax76 post and answers moved to a new trhead: http://forum.doom9.org/showthread.php?t=172144

Xor

20th May 2015, 11:13

how to join two ac3?

I try this command:

eac3to cd1.ac3+cd2.ac3 joined.ac3 -448
and
eac3to cd1.ac3 + cd2.ac3 joined.ac3 -448

but receive error: The format of the source file could not be detected

Boulder

20th May 2015, 11:18

You don't need eac3to for that. You can use the command copy /B cd1.ac3+cd2.ac3 joined.ac3 .

Xor

20th May 2015, 11:51

You don't need eac3to for that. You can use the command copy /B cd1.ac3+cd2.ac3 joined.ac3 .

Thanks, work fine

Xor

20th May 2015, 12:17

Please help me, this command not work, why?

eac3to.exe "AUDIO25.ac3" "AUDIO23976.ac3" -25.000 -changeTo23.976
The format of the source file could not be detected

LigH

20th May 2015, 21:10

Are you really really sure it is AC3?

Can MediaInfo confirm that?

tebasuna51

20th May 2015, 21:49

If ac3 was extracted from a .avi maybe have initial garbage (fake delay used with avi's), you need first fix the ac3 with DelayCut for instance.

DoctorM

21st May 2015, 05:58

Please help me, this command not work, why?

eac3to.exe "AUDIO25.ac3" "AUDIO23976.ac3" -25.000 -changeTo23.976
The format of the source file could not be detected

Do you want -changeto23.976 or do you mean -Slowdown?

tebasuna51

21st May 2015, 08:58

Do you want -changeto23.976 or do you mean -Slowdown?

-slowdown and -25.000 -changeTo23.976 is the same.

eac3to.exe "AUDIO25.ac3" "AUDIO23976.ac3" -25.000 -changeTo23.976

is correct sintax, and also this one:

eac3to cd1.ac3+cd2.ac3 joined.ac3 -448

without spaces between sources (cd1 and cd2 must have the same samplerate, bitrate and num_channels. Also without initial garbage).

Boulder

21st May 2015, 09:19

and also this one:

eac3to cd1.ac3+cd2.ac3 joined.ac3 -448

without spaces between sources (cd1 and cd2 must have the same samplerate, bitrate and num_channels. Also without initial garbage).But in this case, eac3to re-encodes while a normal copy does not.

stax76

24th May 2015, 19:46

might this be a bug?

eac3to v3.29
command line: "C:\Program Files\Staxrip\Apps\eac3to\eac3to.exe" "F:\Neuer Ordner (2)\ID3 German.thd" "F:\Neuer Ordner (2)\ID3 German_out.ac3" -448 -normalize -progressnumbers
------------------------------------------------------------------------------
TrueHD, 5.1 channels, 48kHz
thd, 48000, 5.1
Decoding with libav/ffmpeg...
Writing WAV...
Creating file "F:\Neuer Ordner (2)\ID3 test_out.ac3.pass1.wav"...
Original audio track: max 24 bits, average 20 bits, most common 20 bits.
Caution: The WAV file is bigger than 4GB. <WARNING>
Some WAV readers might not be able to handle this file correctly. <WARNING>
Starting 2nd pass...
Reading WAV...
Remapping channels...
Encoding AC3 <448kbps> with libAften...
Applying -0.07dB gain...
Creating file "F:\Neuer Ordner (2)\ID3 test_out.ac3"...
The processed audio track has a constant bit depth of 64 bits.
eac3to processing took 4 minutes, 39 seconds.
Done.

tebasuna51

24th May 2015, 22:55

might this be a bug?

Maybe, I can't understand how a thd lossless decoder (libav/ffmpeg) can ouput a value at +0.07dB, than need the:
Applying -0.07dB gain...

The <WARNING>'s are ok.

Boulder

25th May 2015, 03:43

I've seen those very small adjustments many times with both TrueHD and DTS-HD MA tracks. I don't know what eac3to considers to be clipping but those ones never trigger that notification so you only see them when you use normalize.

tebasuna51

25th May 2015, 09:17

LigH

26th May 2015, 09:38

I believe that psychoacoustics might sometimes remove frequencies in a way that their loss causes a slight amplification, because their phase was negative thus limiting in rare cases.

GCRaistlin

9th June 2015, 11:58

Why do the result files differ for
eac3to file.ac3 file1.ac3 +96ms
and
eac3to file.ac3 file2.ac3 -edit=0:00:00,+96ms -silence
(file2.ac3 is 1 sample shorter than file1.ac3)?

LigH

9th June 2015, 12:12

1 sample? Isn't AC3 stored in audio blocks of 32 ms each?

GCRaistlin

9th June 2015, 12:19

That's what I mean. file2.ac3 is shifted by 32 ms.

tebasuna51

9th June 2015, 12:47

file2 is a frame (32 ms) shorter than file1, then use always +96ms only.

BTW, the first logic use of edit:

-edit=0:00:00.032,+96ms

works fine.

GCRaistlin

9th June 2015, 12:59

Yes, sorry, I've mixed up frames and samples. But I still don't understand: doesn't "-edit=0:00:00,+96 ms -silence" mean "add 96 ms of silence to the beginning of the file"? In other words, isn't it equal to "+96 ms"?

GCRaistlin

10th June 2015, 11:40

How to take the last minutes of the ac3 file to the wav file with the one command? This:

eac3to file.ac3 file.wav -7200000ms

doesn't work as expected (file.wav is 2:34:01 long, while file.ac3 is 2:04:53 long).

Snowknight26

10th June 2015, 14:26

Use a program that can edit WAV files.

GCRaistlin

10th June 2015, 14:41

Snowknight26, your answer doesn't concern my question. I wonder why this:

eac3to file.ac3 file2.ac3 -7200000ms
eac3to file2.ac3 file2.wav

gives me what I want while the cmdline above doesn't.

Snowknight26

11th June 2015, 15:03

It does fix your problem though.

Sure, it does seem like a bug but I don't think the intention of being able to change a track's delay extended to cutting off 2 hours of audio.

tebasuna51

11th June 2015, 15:05

@madshi
I added a feature request Use ffmpeg like external encoder (http://bugs.madshi.net/view.php?id=310)
Copied here:

To use ffmpeg like external encoder I make some test:

1) eac3to input stdout.wav | ffmpeg -i - -c:a ac3 -b:a 640k wav.ac3

- eac3to send to stdout a wav header with RIFF_length and data_length near to 4 GB, and finish without errors.

- ffmpeg seems work fine with short audios, thats means than do a implicit -ignorelength with piped data.

- Of course with data > 4 GB ffmpeg cut the encode and finish with a file short than input.

2) eac3to input stdout.w64 | ffmpeg -i - -c:a ac3 -b:a 640k w64.ac3

- eac3to send to stdout a w64 header with riff_length and data_length near to 4 GB, and finish with this ERROR, with any input length:

Writing W64...
Creating file "stdout.w64"...
The W64 writer couldn't seek to the header. <ERROR>
Aborted at file position 1886250. <ERROR>

- ffmpeg work until the eac3to crash, but output a encode short than input and a error like:

[pcm_s24le @ 0000000002d19700] Invalid PCM packet, data has size 8 but at least a size of 18 was expected
Error while decoding stream #0:0: Invalid data found when processing input

3) I test ffmpeg piping a w64 file with riff_length and data_length greater than file length and work fine.

Then we can use stdout.w64 with two simple changes, I think, in eac3to:

a) Don't abort with:
The W64 writer couldn't seek to the header. <ERROR>
Like don't abort when use stdout.wav

b) Put a higer value in fields riff_length and data_length of w64 header. Maybe 1 Tera is enough.

FireFreak111

14th June 2015, 06:13

I am trying to extract a TrueHD track from a damaged .ac3 file thats recognised as a H264 file in MKVMerge. When I extract it, compared to the other .ac3 files I am extracting TrueHD tracks from, 'This Track begins with a non-major frame' pops up. This I believe is responsible for the first ~15 seconds of the file either not being decoded or something, causing massive sync issues when muxing the file (audio starts 10-15 seconds or so early). It's the only one where that message pops up, and the only one out of 25 files that has this sync problem. Any idea on how to fix this?

r0lZ

14th June 2015, 06:27

Not sure how to recover the missing 16 seconds, but you can add a delay with MkvMerge (in the tab "Format Specific Options") to re-sync the audio properly.

FireFreak111

14th June 2015, 06:31

Not sure how to recover the missing 16 seconds, but you can add a delay with MkvMerge (in the tab "Format Specific Options") to re-sync the audio properly.

That does fix the sync, but yeah, no audio plays for a while, which for this audio file is a problem.

Soulvomit

16th June 2015, 12:13

How do I get 8.5 minutes of a 145-minute track 25 minutes in? Is sample-accurate editing possible?

gp2221

18th June 2015, 00:49

I used to use 'Another EAC3to GUI' to create MKVs from my Blu-rays. However, I had problems with my hard disk and ended up replacing it and reinstalling my OS (Windows 7 Ultimate x64) and all my programs. Unfortunately, I couldn't get 'Another EAC3to GUI' to work because of a problem with the ArcSoft DTS decoder. I had a legal copy of ArcSoft TMT3, but couldn't get past the 30-day trial. The registration no longer works because TMT3 is a discontinued product. Even though I had the dtsdecoder.dll from the trial installed, I couldn't get 'Another EAC3to GUI' to recognize it. ArcSoft even gave me a new legal copy of TMT6 and I can't get it to work with the decoder from that, either.

I liked that 'Another EAC3to GUI' could generate the audio, video, chapter and subtitle files separately, which I could merge together with MKVmerge (I think the latest version is MKVToolNix GUI). This lets me generate audio-only files from concert Blu-rays. I could use the chapter file to create a CUE file, which I used to to generate FLACs for every track.

So, now that the latest version of eac3to can decode DTS-HD MA, is there an alternative to 'Another EAC3to GUI' that will extract the audio/video + chapters and subtitles?

Nebudchanezzer

18th June 2015, 20:45

gp2221

18th June 2015, 22:40

You can still use "Another EAC3to GUI" just add "-dcadec" after the FLAC filename in the commandline option.
Will I need to edit the command line every time I run it, of is there a way to make this change the default?

Plazik

24th June 2015, 18:11

I've got BD with TV show where each series at the beginning have left saver:
http://i70.fastpic.ru/thumb/2015/0613/ac/67ec1cf324287bdc09d8af853ceca8ac.jpeg (http://fastpic.ru/view/70/2015/0613/67ec1cf324287bdc09d8af853ceca8ac.png.html)
It doesn't shows when I'm plaing playlist but it shows if I'm plaing m2ts file.

BD log:
eac3to v3.29
command line: "C:\Program Files (x86)\MeGUI\tools\eac3to\eac3to.exe" "J:\" -log="filename.txt"
------------------------------------------------------------------------------
1) 00046.mpls, 00037.m2ts, 0:47:14
- Chapters, 6 chapters
- h264/AVC, 1080p24 /1.001 (16:9)
- DTS Master Audio, English, multi-channel, 48kHz
- DTS Master Audio, French, multi-channel, 48kHz

2) 00049.mpls, 00041.m2ts, 0:43:05
- Chapters, 6 chapters
- h264/AVC, 1080p24 /1.001 (16:9)
- DTS Master Audio, English, multi-channel, 48kHz
- DTS Master Audio, French, multi-channel, 48kHz

3) 00048.mpls, 00040.m2ts, 0:43:04
- Chapters, 6 chapters
- h264/AVC, 1080p24 /1.001 (16:9)
- DTS Master Audio, English, multi-channel, 48kHz
- DTS Master Audio, French, multi-channel, 48kHz

4) 00050.mpls, 00053.m2ts, 0:43:01
- Chapters, 6 chapters
- h264/AVC, 1080p24 /1.001 (16:9)
- DTS Master Audio, English, multi-channel, 48kHz
- DTS Master Audio, French, multi-channel, 48kHz

5) 00045.mpls, 00054.m2ts, 0:16:34
- Chapters, 4 chapters
- h264/AVC, 1080p24 /1.001 (16:9)
- AC3, English, stereo, 48kHz
- AC3, English, stereo, 48kHz

Playlist has a right duration 00046.mpls, 00037.m2ts, 0:47:14.

But detailed information of the playlist has another information 0:50:03:

eac3to v3.29
command line: "C:\Program Files (x86)\MeGUI\tools\eac3to\eac3to.exe" "J:\" 1) -log="filename.txt"
------------------------------------------------------------------------------
M2TS, 1 video track, 2 audio tracks, 8 subtitle tracks, 0:50:03, 24p /1.001
1: Chapters, 6 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: DTS Master Audio, English, 5.1 channels, 24 bits, 48kHz
(core: DTS, 5.1 channels, 768kbps, 48kHz)
4: DTS Master Audio, French, 5.1 channels, 24 bits, 48kHz
(core: DTS, 5.1 channels, 768kbps, 48kHz)
5: Subtitle (PGS), English
6: Subtitle (PGS), French
7: Subtitle (PGS), Danish
8: Subtitle (PGS), Dutch
9: Subtitle (PGS), Finnish
10: Subtitle (PGS), Norwegian
11: Subtitle (PGS), Swedish
12: Subtitle (PGS), French

I can't demux video and audio correct.

Bigmango

29th June 2015, 20:45

Hi,

Is there a problem with the FLAC 4 channel mapping?

This is my DTS-HDMA track:
Channel(s) : 4 channels
Channel positions : Front: L C R, Back: C

But according to the FLAC specs, this is the assignment for 4 channels:
3 channels: left, right, center
4 channels: front left, front right, back left, back right

Makemkv outputs an error, explaining that the channel mapping will be wrong as FLAC doesn't support these 4 channels correctly.

eac3to detects this as 3.1. But will the channel layout be right?

Thanks.

nevcairiel

29th June 2015, 21:22

Bigmango

4th July 2015, 13:48

eac3to will write metadata to the FLAC file which sets the appropriate channel layout beyond what the FLAC spec allows - it then entirely depends on your playback application if it can read this metadata and properly make use of it.

As far as I can seen, the resulting eac3to FLAC doesn't contain any metadata at all. Playback with MPC-HC and VLC sounds with a wrong layout.

Makemkv does, but the layout is wrong and it also ouputs an error message explaining why (FLAC doesn't support 3.1, makemkv writes a 4.0 layout).

Why can't FLAC support the layouts like HD audio ? Again some kitchentable developpers thinking their way is the best (based on the microsoft layout or what?) so this is a reason FLAC can't be compatible with some HD audio tracks (which ARE an insdustry standart) ???

So, it isn't possible to backup some HD tracks to FLAC.

For christ's sake...

WAV seems to be a much more complete format. With W64 eac3to writes the correct layout.

So the only choices seem to be:
1. W64, but there's no compression so its a huge file (wavpack still doesnt' support 4Gb files.... we are in 2015 dear Jesus!)
2. Keeping the DTS-HDMA....

What are the devs (xiph ?) waiting for to complete the FLAC format channel layouts properly? If WAV can, why can't FLAC do it?

Thanks for the feedback.

nevcairiel

4th July 2015, 14:39

Like I said, there is an informal spec for extra channel layout information, and a lot of tools support it just fine. Its not the formats fault if your tool or your workflow fail to use it.
Since madshi was one of the people that helped create this extra layout information, I'm sure eac3to can also handle it.

Edit:
In fact, I just tested, used a 3.1 DTS sample clip, converted it to FLAC with eac3to, and it set the appropriate metadata tag (ie. WAVEFORMATEXTENSIBLE_CHANNEL_MASK=0XF, which means front L/R, center, LFE)
Plays as 3.1 in MPC-HC, too, and MediaInfo reports the appropriate channel mapping for the FLAC file.

Bigmango

4th July 2015, 23:09

Like I said, there is an informal spec for extra channel layout information, and a lot of tools support it just fine. Its not the formats fault if your tool or your workflow fail to use it.

Why is it informal ? So hardware players and other players will never support it?

eac3to doesn't write channel layout metadata.

Makemkv does. Are there any other tools?

Since madshi was one of the people that helped create this extra layout information, I'm sure eac3to can also handle it.

There are several posts about such problems (also discussing why eac3to doesn't write channel layouts when makemkv does), and madshi always said writing channel layouts is useless. What he does with eac3to is moving the channel's around so that the layout matches the FLAC standard layouts when some tracks have a special layout.

And here the problem is that FLAc only has 4.0 (front left, front right, back left, back right). My DTSMA track is 3.1 (Front: L C R, Back: C), so it is not possible with FLAC. And the ffmpeg encoder in makemkv outputs an error to warn that the channels won't be layout properly.

As you are talking about my tool chain being bad, what other tools do you know of other than eac3to, makemkv and ffmpeg based tools that do work, as these don't?

Edit:
In fact, I just tested, used a 3.1 DTS sample clip, converted it to FLAC with eac3to, and it set the appropriate metadata tag (ie. WAVEFORMATEXTENSIBLE_CHANNEL_MASK=0XF, which means front L/R, center, LFE)
Plays as 3.1 in MPC-HC, too, and MediaInfo reports the appropriate channel mapping for the FLAC file.

My eac3to never writes channel layouts for FLAC and madshi said several times he won't do it with FLAC. Mediainfo shows no layout metadata. I'm using eac3to 3.29.

After converting this track with eac3to I can also clearly hear with MPC-HC that the channel mapping is wrong.

Why do you get channel mappings in mediainfo with eac3to when I don't, and when madshi said many times he won't do it? What am I missing?

Thanks.

nevcairiel

4th July 2015, 23:13

eac3to 3.29 just works for me, reading DTS 3.1 and writing FLAC. Can't tell you anything else. And I doubt that madshi said that he won't do it, as I know for a fact that he helped define this metadata for FLAC specifically.
Nothing magical, just "eac3to input.dts output.flac"

The only time it wouldn't write this metadata is when the layout matches the implicit FLAC layout anyway (ie. when its 4.0)

ffmpeg should also support this layout, at least reading it. Not sure if it can write it, but it might.

DarkSpace

4th July 2015, 23:26

A while back, I happened to try out ffmpeg's channel layouts, and I can tell for certain that (with a null source, because it was just a test) it added a WAVE_FORMAT_EXTENSIBLE tag to the output flac.
Further, I distinctly remember bugging nevcairiel (https://code.google.com/p/lavfilters/issues/detail?id=342) about these very tags that eac3to writes, so LAV Filters would honor them.

Edit: It may also have been a WAVEFORMATEXTENSIBLE tag, I don't remember for certain. What I do remember, though, is that it used the tag that signals a non-default channel layout.

Edit 2: Also, since it's in the changelog (https://xiph.org/flac/changelog.html#flac_1_1_3) ("Encoder can now take WAVEFORMATEXTENSIBLE WAVE files as input; decoder will output WAVEFORMATEXTENSIBLE WAVE files when necessary to conform to the latest Microsoft specifications."), it may even be more than just informal.

Bigmango

5th July 2015, 00:36

I tired again, here is the mediainfo output:

Source:

Audio
Format : DTS
Format/Info : Digital Theater Systems
Format profile : MA / Core
Mode : 16
Format settings, Endianness : Big
Bit rate mode : Variable
Bit rate : Unknown / 1 509 Kbps
Channel(s) : 4 channels
Channel positions : Front: L C R, Back: C
Sampling rate : 48.0 KHz
Bit depth : 24 bits
Compression mode : Lossless / Lossy

FFMPEG 2.7:
While encoding it shows this error in red: Channel layout not supported by Flac, output stream will have incorrect channel layout.
But it writes the layout tag fine.

Audio
Format : FLAC
Format/Info : Free Lossless Audio Codec
Duration : 2h 13mn
Bit rate mode : Variable
Bit rate : 2 604 Kbps
Channel(s) : 4 channels
Channel positions : Front: L C R, Back: C
Sampling rate : 48.0 KHz
Bit depth : 24 bits
Stream size : 2.42 GiB (100%)
Writing library : Lavf56.36.100

eac3to 3.29:
As I said, no channel layout metadata at all. As I understand, this means it will use 4.0, which is wrong.

Audio
Format : FLAC
Format/Info : Free Lossless Audio Codec
Duration : 2h 13mn
Bit rate mode : Variable
Bit rate : 2 612 Kbps
Channel(s) : 4 channels
Sampling rate : 48.0 KHz
Bit depth : 24 bits
Stream size : 2.43 GiB (100%)
Writing library : libFLAC 1.2.1 (UTC 2007-09-17)

VLC shows this in codec information:
DTSHDMA source: channels 3F1R
ffmpeg FLAC: channels 2F2R
eac3to FLAC: channels 2F2R

2F2R is FLAC 4.0, according to the FLAC format specs this is the only 4 channel layout supported.

ndjamena

5th July 2015, 01:14

Whatever version of VLC you're using is obviously buggy and doesn't read the tag yet. If the latest nightly can't read the layout tag you should report it on the bug tracker if it hasn't been done already.

What version of MediaInfo are you using? Old versions can't read layout tags with an uppercase 'X' in the hexidecimal value.

When MakeMKV complains about the layout, what is it actually saying? MakeMKV has been using the tags exclusively to denote layouts and has only learned to use the defaults for decoding since the latest release (thanks to madashi), but it does use FFMPEG internally for decoding and encoding FLAC. Is the error message from FFMPEG or MakeMKV itself? The layout is just a mask, as long as each channel position exists in the .wav layout specs you should be able to use any combination you like with impunity.

madshi

5th July 2015, 06:27

@Bigmango, first of all, please adjust your attitude. Belittling developers as "kitchentable developers" (no matter who you mean) is insulting. A bit more respect to devs who work their ass off to write software for you for free would look good on you.

Why is it informal ? So hardware players and other players will never support it?
Attitude, once again.

When FLAC was created, everybody used it for CD/Audio. Nobody used it for movies back then, because we only had DVD and there was no sense reencoding the DVD lossy tracks to FLAC. All this changed with Blu-Ray, which was released a loooong time after the FLAC spec was created. The original FLAC spec has a fixed channel speaker config for every channel number, but didn't have the option to define custom speaker defs. That was later added via metadata tag. This addition is not mentioned in the current spec, but it was confirmed to be "officially endorsed" by the FLAC dev. eac3to has been writing this metadata tag for many years now.

eac3to doesn't write channel layout metadata.
Flat out incorrect. eac3to does write channel layout metadata, but only if it's needed (which means if the default FLAC channel config differs from the actual channel config). Which means eac3to perfectly adapts to the FLAC spec.

My eac3to never writes channel layouts for FLAC and madshi said several times he won't do it with FLAC. Mediainfo shows no layout metadata.
Get your facts straight. I never said any such thing. If Mediainfo doesn't show layout metadata then that's a bug (or missing support for the channel config metadata) in Mediainfo.

I remember a similar problem was reported just a couple of pages ago in this very thread, and the user who complained ended up sending bug reports to the MediaInfo dev, which IIRC were accepted. So maybe just updating your MediaInfo version might already solve the issue (with MediaInfo). Not sure, but my memory tells me MediaInfo might have ignored the channel config metadata if it had the wrong case (lower case vs upper case letters), or something like that.

I don't know what decoders do or don't do with the FLAC channel config. Don't even remember if madFlac implements that properly. Seems LAV does, though, so try LAV.

ndjamena

5th July 2015, 08:30

I remember a similar problem was reported just a couple of pages ago in this very thread, and the user who complained ended up sending bug reports to the MediaInfo dev, which IIRC were accepted. So maybe just updating your MediaInfo version might already solve the issue (with MediaInfo). Not sure, but my memory tells me MediaInfo might have ignored the channel config metadata if it had the wrong case (lower case vs upper case letters), or something like that.

That bug was fixed, so the latest MediaInfo SHOULD read any WAVEFORMATEXTENSIBLE tag placed in a file correctly (unless there's some other oddity involved.)

FLAC defaults in MediaInfo are pending. I've been waiting almost 2 years for MediaInfo to report a DTS-ES core in DTS-HD so I don't know how long it will take to get FLAC defaults done. I've tried looking at the code but although it seems simple enough it's way beyond my skill level. I reported the same problem to MakeMKV and it was fixed within days, so for me at least MediaInfo is now the odd man out.

Bigmango

5th July 2015, 10:40

Many thanks to all of you people helping me out with this issue.

Whatever version of VLC you're using is obviously buggy and doesn't read the tag yet. If the latest nightly can't read the layout tag you should report it on the bug tracker if it hasn't been done already.

Ok, I'll have a look at the bug tracker and report it.

What version of MediaInfo are you using? Old versions can't read layout tags with an uppercase 'X' in the hexidecimal value.

Holly Jesus, I updated mediainfo and it now shows the tags for the eac3to FLAC. :D

When MakeMKV complains about the layout, what is it actually saying? MakeMKV has been using the tags exclusively to denote layouts and has only learned to use the defaults for decoding since the latest release (thanks to madashi), but it does use FFMPEG internally for decoding and encoding FLAC. Is the error message from FFMPEG or MakeMKV itself? The layout is just a mask, as long as each channel position exists in the .wav layout specs you should be able to use any combination you like with impunity.

Makemkv is spitting out an ffmpeg error line with the same error as when encoding with ffmpeg 2.7 directly (Channel layout not supported by Flac, output stream will have incorrect channel layout.), but continues its works and the resulting FLAC has a 4.0 channel layout with the default FLAC 2F2R channels for 4.0.

As ffmpeg 2.7 is writing the correct layout I am guessing 2 possible reasons for this:

either makemkv uses an older version of ffmpeg that doesn't work as version 2.7
or makemkv modifies the layout to write it by itself, this would be a makemkv bug?

Bigmango

5th July 2015, 11:01

When FLAC was created, everybody used it for CD/Audio. Nobody used it for movies back then, because we only had DVD and there was no sense reencoding the DVD lossy tracks to FLAC. All this changed with Blu-Ray, which was released a loooong time after the FLAC spec was created. The original FLAC spec has a fixed channel speaker config for every channel number, but didn't have the option to define custom speaker defs. That was later added via metadata tag. This addition is not mentioned in the current spec, but it was confirmed to be "officially endorsed" by the FLAC dev.

In the same way FLAC added the 6.1 layout with version 1.3, why don't they add these tags to the spec so all the players including hardware players can support complete channel layout properly, like the commercial HD codecs?

Today some older players still can't play the 6.1 channel files as they were made before the introduction of 6.1 in the spec. With these tags we would have the same issue of older players not playing back correctly. This problem doesn't seem to be an issue as we already had it with 6.1, so why don't they do it with the tags ? We would have an opensource 100% replacement for codecs like DTSHDMA.

Or at least they could add the 3.1 layout to the spec (as they did with 6.1).

eac3to has been writing this metadata tag for many years now.

Flat out incorrect. eac3to does write channel layout metadata, but only if it's needed (which means if the default FLAC channel config differs from the actual channel config). Which means eac3to perfectly adapts to the FLAC spec.

Get your facts straight. I never said any such thing.

There were several posts a few months earlier in this thread where people asked why eac3to didn't write the channel layout tags like makemkv, and you replied that FLAC was using the standard WAV layouts so there was no need to write the tags, and in case a track was using a strange setup you were moving the channels around with eac3to to match the default layout, so again you said there was no need to write the tags.

A few months ago prior to the new version mediainfo also didn't show any tags written by eac3to.

Perhaps what you said was all a misunderstanding then. Anyway I now see the tags with the new mediainfo, so all is well, thanks.

If Mediainfo doesn't show layout metadata then that's a bug (or missing support for the channel config metadata) in Mediainfo.

I remember a similar problem was reported just a couple of pages ago in this very thread, and the user who complained ended up sending bug reports to the MediaInfo dev, which IIRC were accepted. So maybe just updating your MediaInfo version might already solve the issue (with MediaInfo). Not sure, but my memory tells me MediaInfo might have ignored the channel config metadata if it had the wrong case (lower case vs upper case letters), or something like that.

I don't know what decoders do or don't do with the FLAC channel config. Don't even remember if madFlac implements that properly. Seems LAV does, though, so try LAV.

Yes, the new mediainfo sees the tags. :)

It would be so much better if FLAC just added these tags to the spec, as they did in version 1.3 with the 6.1 channel layout. So everyone could support this in the future.

:thanks:

ndjamena

5th July 2015, 11:19

I'll handle the MakeMKV FLAC bug, it seems to be my baby.

Bigmango

5th July 2015, 12:07

One more question:

As I understand, eac3to and ffmpeg are writing the channel layout tags differently.

This resulted in the problem with mediainfo only displaying the tags for ffmpeg FLAC and not for eac3to FLAC.

So, players and sofware now have to support 2 different ways of reading the tags. This means, as with mediainfo, we could get some players playing back correctly only some FLACs (i.ex made by ffmpeg) and not others (i.ex made by eac3to) if the developpers don't implement both different ways of reading the tags.

Can't the developers all follow the same way of writing the tags? Isn't this an unnecessary complication, leading to bugs as it happened with mediainfo?

(I guess this messy situation where everyone tries to implement his own way of doing things is one more result of the incomplete FLAC spec. What are the FLAC devs waiting for to add tags to the spec or at least the 3.1 channel layout ? (again: they did it for 6.1, why not 3.1))

I'll handle the MakeMKV FLAC bug, it seems to be my baby.

:thanks:

ndjamena

5th July 2015, 12:34

The prefix for hexadecimal numbers is '0x', I've only seen it in lower case, but apparently '0X' is acceptable too. It's not really a problem with the tags... I tend to think '0x' is correct but really hexadecimal is case insensitive so either should work fine in most programs. it's just MediaInfo was checking for an '0x' before it proceeded to interpret the tag and when it didn't find one it aborted. Most programs would just pass the hex number in full to a conversion function, which shouldn't care which case is used. (MakeMKV always uses '0x' yet it didn't flinch at the '0X prefix).

madshi

5th July 2015, 13:06

In the same way FLAC added the 6.1 layout with version 1.3, why don't they add these tags to the spec so all the players including hardware players can support complete channel layout properly, like the commercial HD codecs?
You'd have to ask the FLAC maintainers that.

Anyway, the metadata tag used by eac3to has been "known" for years. Actually at least 10 years, I've just checked. So there's nothing stopping players including hardware players from supporting it. But of course it would be better to mention this specific metadata tag directly in the FLAC spec. But nobody on doom9 has power over the FLAC spec, so if you want something changed there, you have to ask the FLAC guys about it, not us here.

There were several posts a few months earlier in this thread where people asked why eac3to didn't write the channel layout tags like makemkv, and you replied that FLAC was using the standard WAV layouts so there was no need to write the tags, and in case a track was using a strange setup you were moving the channels around with eac3to to match the default layout, so again you said there was no need to write the tags.
Nope, that is not a correct summary of what I said. eac3to writes the channel layout tag if it's needed (and only if it's needed). It has always done that.

Perhaps what you said was all a misunderstanding then. Anyway I now see the tags with the new mediainfo, so all is well, thanks.
If there was a misunderstanding, then it was on your part.

As I understand, eac3to and ffmpeg are writing the channel layout tags differently.
No. They write them exactly the same way, except that ffmpeg partially uses lower case letters while eac3to uses upper case letters. When reading text metadata (especially if it's a hexadecimal value as in this situation), upper/lower case should usually be ignored. mediainfo didn't do that, so it was a simple bug in mediainfo, which is fixed now, nothing more.

FYI, libav/ffmpeg just added support for the channel speaker metadata tag about a year ago. Probably mediainfo added support for it around the same time. eac3to has had support for this for 8 years now. Go figure.

Bigmango

5th July 2015, 13:15

@ madshi ok, thanks for the feedback.

Edit 2: Also, since it's in the changelog (https://xiph.org/flac/changelog.html#flac_1_1_3) ("Encoder can now take WAVEFORMATEXTENSIBLE WAVE files as input; decoder will output WAVEFORMATEXTENSIBLE WAVE files when necessary to conform to the latest Microsoft specifications."), it may even be more than just informal.

Hallelujah DarkSpace ! :thanks:

Yes, and even more so (FLAC 1.1.3 (27-Nov-2006) changelog):

Encoder can now take WAVEFORMATEXTENSIBLE WAVE files as input; decoder will output WAVEFORMATEXTENSIBLE WAVE files when necessary to conform to the latest Microsoft specifications.
Now properly supports AIFF and WAVEFORMATEXTENSIBLE multichannel input, performing necessary channel reordering both for encoding and decoding. WAVEFORMATEXTENSIBLE channel mask is also saved to a tag on encoding and restored on decoding for situations when there is no natural mapping to FLAC channel assignments.

So this seems to be a non-issue since FLAC 1.1.3 (27-Nov-2006).

But then why:

does ffmpeg output this error "Channel layout not supported by Flac, output stream will have incorrect channel layout" (and what are the consequences of this?)
does the latest MPC-HC 1.7.9 show in the file properties "A: flac, 48000 Hz, 4.0, s24" -> 4.0 when it should be 3.1
does makemkv convert the 3.1 3F1R DTSHDMA to 4.0 2F2R FLAC (writing these tags in the FLAC)
does VLC 2.2.1 in the properties show 4.0 2F2R instead of 3.1 3F1R

FLAC supports this since 2006, why don't these tools?

The problem seems to be that all the tools should read the WAVEFORMATEXTENSIBLE channel mask, but they don't ?

Is this because FLAC only wrote this in the 1.1.3 changelog, but they didn't add it to the online format spec, so the other tools aren't using this (some *but not all* do it informally as said above) ? If it is in the 1.1.3 changelog, why isn't it in the spec?

Summary: why is this a problem at all if it is supported by FLAC since 2006?

ndjamena

5th July 2015, 13:36

http://sourceforge.net/p/mediainfo/feature-requests/313/

2011-02-09

It was at least partially implemented since then.

These programs are all buggy/out of date. I don't know what MakeMKVs current problem is, it didn't even seem to know defaults existed a few weeks ago. I'll assume they just were overzealous with their implementation of "defaults". (What version are you using? Have you tried an older version?)

It's our job to get all these programs working, there's not much point in complaining about it here.

-edit- why do I get the feeling I'm on Madashis ignore list...

madshi

5th July 2015, 13:52

@ndjamena, sorry, I probably re-explained some things you had already covered. You're *not* on my ignore list.

@Bigmango. "3.1" is not correct. The correct name should be "3/1". At least that's how Dolby names it, and eac3to, too.

Bigmango

5th July 2015, 13:53

These programs are all buggy/out of date. I don't know what MakeMKVs current problem is, it didn't even seem to know defaults existed a few weeks ago. I'll assume they just were overzealous with their implementation of "defaults". (What version are you using? Have you tried an older version?)

I now made sure I am using the latest version of all the tools.

It's our job to get all these programs working, there's not point in complaining about it here.

I'm just asking to make sure I didn't miss something before talking about individual tool bugs specifically.

And since FLAC supports this since 2006, I can't imagine why all the tools don't support it in 2015. Who is the culprit? Who should fix this? Is it a bug in all of the tools, or is it a problem of FLAC writing something (WAVEFORMATEXTENSIBLE channel mask support) in the changelog without adding it to the format spec?

Thanks.

Bigmango

5th July 2015, 14:17

Bigmango

5th July 2015, 14:51

There seem to be too many problems with FLAC playback and non standard channel layouts (but then, DTS-HDMA is a standard, so can 3/1 DTS-HDMA layouts be considered as non-standard?).

Wavpack is currently adding 4+ Gb file support in the next version (which the dev said last february should be comming very soon).

2 questions considering the above:

is wavpack a good replacement for multichannel FLAC, especially when used with mkv. What about playback compatibility?
will eac3to add support for wavpack, especially considering the problems FLAC playback has with some channel layouts?

Thanks.

ndjamena

5th July 2015, 15:43

wavpack in MKV is completely useless. It has no channel layout at all. It's on the MKVToolNix bug tracker somewhere. MKVMerge will simply remove any layout info from the track because THERE IS NO WAY TO GIVE WAVPACK CHANNEL LAYOUTS IN AN MKV.

(and Mosu can't be bothered fixing that... PCM has no channel layout either, but the developer of MakeMKV went through hell to invent a codec to give it one.)

Bigmango

5th July 2015, 16:03

Thanks for the feedback ndjamena.

Then I'll keep the original DTS-HDMA track untill FLAC gets fixed.

Considering all of the above, why didn't FLAC go with WAVEFORMATEXTENSIBLE channel mask from the start instead of the current incomplete channel mappings.

FLAC really needs to add this to the format spec as it seems the tools will not support it without this even if it has been supported by FLAC for the past 10 years.

nevcairiel

5th July 2015, 16:11

But then why:

does the latest MPC-HC 1.7.9 show in the file properties "A: flac, 48000 Hz, 4.0, s24" -> 4.0 when it should be 3.1

3.1 would be 3 channels and a subwoofer. The dot notation does not split front and back channels like this.
If the file contains metadata, MPC-HC will play it properly.

madshi

5th July 2015, 16:16

After playing back on my Yamaha receiver with the latest kodi (xbmc) 15 RC (uses a recent version of ffmpeg 2.6.x), here is the result:

(source DTS-HDMA 3/1)
(eac3to & ffmpeg FLAC : mediainfo shows correct 3/1 channel layout)

Track information on the Yamaha receiver:
DTS-HDMA source : channels 4.0 (3/1)
eac3to & ffmpeg FLAC : PCM channels 4.0 (2/2)

This means the latest ffmpeg versions write the channel layout tags correctly (as eac3to), but they don't play it back with the right channel layout.

This also means the eac3to 3/1 FLACs are not played back correctly, but eac3to doesn't issue any warning (as ffmpeg does when encoding "Channel layout not supported by Flac, output stream will have incorrect channel layout").

Shouldn't eac3to give a warning?
eac3to's job is to produce a correct FLAC file, and that's what it does. So eac3to has no reason to warn about anything.

I don't know if HDMI supports 3/1 PCM transport. Maybe it doesn't? I've no idea. If it doesn't, then maybe 3/1 should simply be extended to 7.1 by adding empty channels? I don't know, and that's clearly outside of what this thread is about.

And who should I write the bug report to (as per my above post, FLAC or all the tools (ffmpeg and all the tools not using ffmpeg like VLC)) ?
Anyone but eac3to, because eac3to does things exactly right. If you find that other projects have bugs, complain to them.

I think at this point it's time to stop this discussion in this thread. This thread is about eac3to, and not about bugs in other projects like Kodi, ffmpeg, VLC, mediainfo or whatever.

Bigmango

5th July 2015, 16:52

Thanks for the feedback everyone.

eac3to's job is to produce a correct FLAC file, and that's what it does.

Yes of course. It can't do anything better with the broken/incomplete FLAC format specs (broken because incomplete).

So eac3to has no reason to warn about anything.

Ok. But the problem is that it writes files that will play back with a wrong channel layout for 3/1 (and what else? We don't know if other less used layouts will have problems as well as it doesn't give a warning with the bad player support for 3/1) with the majority of players (all commercial players, everything ffmpeg based, vlc,...).

According to the feedback above only the lav filters and perhaps MPC-HC will play the eac3to 3/1 correctly.

As this is a problem with the majority of players, this is imho an issue big enough to be worthy of a warning (ffmpeg decided it was as they added an error warning).

Anyone but eac3to, because eac3to does things exactly right. If you find that other projects have bugs, complain to them.

Ok.

I think at this point it's time to stop this discussion in this thread. This thread is about eac3to, and not about bugs in other projects like Kodi, ffmpeg, VLC, mediainfo or whatever.

Yes. But I think it was important to talk about this as the majority of players will not play back the 3/1 eac3to FLAC files correctly AND most users will never know this with no warning (and what else will be wrong in play back? we don't know as eac3to doesn't issue a warning as it does it in the best way it can with the current FLAC spec).

eac3to should tell users the FLAC spec is incomplete for this layout (and what about other layouts) and that playback problems may arise with many players.

If I hadn't tried encoding with makemkv and ffmpeg I would have never known there was a playback problem with my eac3to flac file.

madshi

5th July 2015, 18:13

I don't have the resources to test any and every funny format and speaker config. I suppose there will probably many more than 3/1 which may produce problems with some software or hardware players. And it won't be limited to FLAC, either. Warning about bugs in other software or hardware is not eac3to's job. The only thing I worry about is whether eac3to produces correct files. As long as it does, I'm satisfied. So instead of bugging me to add a warning, better spend your time getting the real bugs fixed in the other software/hardware. You're barking up the wrong tree here. It seems eac3to is one of the few parts of your tool collection which works correctly. So why do you bother *me* with change requests and complaints?

Btw, I think that using LAV Audio Decoder to decode eac3to's 3/1 FLAC files will probably produce the same results as playing 3/1 WAV files, or letting LAV Audio Decoder decode 3/1 DTS files in real time during playback. So I think this issue is not FLAC specific.

In any case, this is my last post about this topic.

Bigmango

5th July 2015, 20:18

Many thanks for the comprehensive feedback madshi.

I submitted bugs to ffmpeg #4698 (https://trac.ffmpeg.org/ticket/4698), VLC #15005 (https://trac.videolan.org/vlc/ticket/15005) and FLAC #430 (https://sourceforge.net/p/flac/bugs/430/).

We'll see what comes out of this. Hopefully FLAC will be a complete codec, one way or another.

ndjamena

6th July 2015, 03:06

We'll see what comes out of this. Hopefully FLAC will be a complete codec, one way or another.

Yup, FLAC will finally get out of the CD era and get a proper implementation of channel layouts... just as Dolby Atmos and DTS:X begin to render the whole thing obsolete. :scared:

Mike Chen

7th July 2015, 11:29

As ffmpeg 2.7 is writing the correct layout I am guessing 2 possible reasons for this:

either makemkv uses an older version of ffmpeg that doesn't work as version 2.7
or makemkv modifies the layout to write it by itself, this would be a makemkv bug?

As of now, MakeMKV uses libavcodec from ffmpeg 2.1 . I'll update the libs in next release.

laz1989

20th July 2015, 09:41

Hello guys,
After i read the eac3to tutorial, and even google it 100 times i didn't found a solution at this problem so i try to post here maybe someone will help me.
I have a Bluray with TrueHD and i want to extract the audio in 640 .ac3
With nero :

C:\Users\Desktop\eac3to>eac3to.exe D:\test.thd test.ac3 -nero
TrueHD, 5.1 channels, 48kHz
thd, 48000, 5.1
Disabling DRC for Nero (E-)AC3 decoding...
Decoding with DirectShow (Nero Audio Decoder 2)...
The DirectShow audio decoder didn't accept the input stream.
Aborted at file position 262144.

Whitout nero :

C:\Users\Desktop\eac3to>eac3to.exe D:\test.thd test.ac3
TrueHD, 5.1 channels, 48kHz
thd, 48000, 5.1
Decoding with libav/ffmpeg...
Remapping channels...
Encoding AC3 <640kbps> with libAften...
The libav decoder reported error -1094995529 while decoding.

And there it's the eac3to test.

C:\Users\Desktop\eac3to>eac3to -test
eac3to (v3.29) is up to date
Nero Audio Decoder (Nero 7) works fine
ArcSoft DTS Decoder (1.1.0.8) works fine
Sonic Audio Decoder (4.3.0.169) works fine
Haali Matroska Muxer (2013-04-14) is installed
There's a new version (2013-06-23) available
http://haali.net/mkv
Nero AAC Encoder (1.5.4.0) is up to date
Surcode DTS Encoder (1.0.29.0) is installed

IF someone can help me, i will be greatful.
Cheers!

tebasuna51

20th July 2015, 11:00

...
Decoding with libav/ffmpeg...
...
The libav decoder reported error -1094995529 while decoding.

Or your test.thd is corrupt or have some caracteristics not supported by libav decoder.

You can try with the last ffmpeg (http://ffmpeg.zeranoe.com/builds/) version:

ffmpeg.exe -i test.thd -acodec ac3 -ab 640k test.ac3

If still don't work and your test.thd play fine with some player you can upload a sample to ffmpeg developers.

laz1989

20th July 2015, 11:22

Thanks for your answer @tebasuna51.
Already try that before post here.

[truehd @ 04cb2d40] Lossless check failed - expected 13, calculated 1f.
[NULL @ 04caa440] mlpparse: Parity check failed.
[truehd @ 04cb2d40] Lossless check failed - expected 43, calculated 38.
[NULL @ 04caa440] mlpparse: Parity check failed.
[truehd @ 04cb2d40] Lossless check failed - expected 2a, calculated 1d.
[NULL @ 04caa440] mlpparse: Parity check failed.
[truehd @ 04cb2d40] Lossless check failed - expected c7, calculated 5f.
[NULL @ 04caa440] mlpparse: Parity check failed.
[truehd @ 04cb2d40] Lossless check failed - expected 9a, calculated 88.
[NULL @ 04caa440] mlpparse: Parity check failed.
[truehd @ 04cb2d40] Lossless check failed - expected 43, calculated d7.
[NULL @ 04caa440] mlpparse: Parity check failed.
[truehd @ 04cb2d40] Lossless check failed - expected 7f, calculated f9.
[NULL @ 04caa440] mlpparse: Parity check failed.
[truehd @ 04cb2d40] Lossless check failed - expected 6f, calculated 37.
[NULL @ 04caa440] mlpparse: Parity check failed.
[truehd @ 04cb2d40] Lossless check failed - expected dc, calculated a0.
[NULL @ 04caa440] mlpparse: Parity check failed.
[truehd @ 04cb2d40] Lossless check failed - expected 13, calculated d0.
[NULL @ 04caa440] mlpparse: Parity check failed.
[truehd @ 04cb2d40] Lossless check failed - expected 47, calculated 3b.
[NULL @ 04caa440] mlpparse: Parity check failed.
[truehd @ 04cb2d40] Lossless check failed - expected 8e, calculated 2a.
[NULL @ 04caa440] mlpparse: Parity check failed.
[truehd @ 04cb2d40] Lossless check failed - expected b6, calculated 81.
[NULL @ 04caa440] mlpparse: Parity check failed.
[truehd @ 04cb2d40] Lossless check failed - expected da, calculated 6a.
[NULL @ 04caa440] mlpparse: Parity check failed.
[truehd @ 04cb2d40] Lossless check failed - expected b7, calculated 7a.
[NULL @ 04caa440] mlpparse: Parity check failed.
[truehd @ 04cb2d40] Lossless check failed - expected 40, calculated e8.
[NULL @ 04caa440] mlpparse: Parity check failed.
[truehd @ 04cb2d40] Lossless check failed - expected 8c, calculated 7c.
[NULL @ 04caa440] mlpparse: Parity check failed.
[truehd @ 04cb2d40] Lossless check failed - expected 32, calculated 25.
[NULL @ 04caa440] mlpparse: Parity check failed.
[truehd @ 04cb2d40] Lossless check failed - expected c4, calculated f9.
[NULL @ 04caa440] mlpparse: Parity check failed.
[truehd @ 04cb2d40] Lossless check failed - expected 29, calculated 10.
[NULL @ 04caa440] mlpparse: Parity check failed.
Last message repeated 13 times
size= 31002kB time=00:06:38.80 bitrate= 636.8kbits/s
video:0kB audio:31002kB subtitle:0kB other streams:0kB global headers:0kB muxing
overhead: 0.000000%

And yes, the .thd it's not corrupt since it plays well different players.
I would wish more to find a problem to that nero encode since that seems the proper way to go from thd to ac3.

sneaker_ger

20th July 2015, 11:27

Is there any reason not to extract the core from the Blu-Ray? Free AC3 encoders don't have such a good reputation anyways.

laz1989

20th July 2015, 11:39

Is there any reason not to extract the core from the Blu-Ray? Free AC3 encoders don't have such a good reputation anyways.

How do i do that? I used both megui and eac3to cmd.
In MeGui i selected AC3 and didn't work. :)

Nebudchanezzer

20th July 2015, 12:42

How do i do that? I used both megui and eac3to cmd.
In MeGui i selected AC3 and didn't work. :)

Does not "-core" work?

Xor

20th July 2015, 14:21

Please help me, i have extracted 2 audio track LPCM in RAW format, i need to convert to ac3.

For eng track i have converted without problems

d:\eac3to327>eac3to.exe "ENG.raw" ENG.ac3
This might be a RAW/PCM file. Trying to figure out the details.
This will probably take a while. Please be patient...
The RAW/PCM file seems to be little endian.
The RAW/PCM file seems to have a bitdepth of 24 bits.
The RAW/PCM file seems to have 2 channels.
RAW/PCM, 2.0 channels, 1:29:51, 24 bits, 2304kbps, 48kHz
Reading RAW/PCM...
Encoding AC3 <448kbps> with libAften...
Creating file "ENG.ac3"...
The original audio track has a constant bit depth of 24 bits.
eac3to processing took 41 seconds.
Done.

for other Raw track italian eac3to ask me to specify other parameters:
d:\eac3to327>eac3to.exe "ITA.raw" ITA.ac3 -448
This might be a RAW/PCM file. Trying to figure out the details.
This will probably take a while. Please be patient...
Was not able to figure out all parameters of this RAW/PCM file.
Please specify channel, bitdepth and endian parameters via command line.

How to configure command line to convert to ac3 this raw eac3to.exe "ITA.raw" ITA.ac3 ??? ???

Thanks

tebasuna51

20th July 2015, 14:38

Xor

20th July 2015, 14:51

@Xor
Never extract audio tracks LPCM like raw, use wav or w64 format to avoid this problem, the data samples are the same.

If you know than ITA.raw have the same parameters than the ENG.raw use:

eac3to.exe "ITA.raw" ITA.ac3 -448 -override -2 -24 -little -48000

Also the bitrate for 2 channels is enough with 256 Kb/s

BIG THANKS!!! Work fine

d:\eac3to327>eac3to.exe "ITA.raw" ITA.ac3 -448 -override -2 -24 -little -48000
RAW/PCM, 2.0 channels, 1:29:51, 24 bits, 2304kbps, 48kHz
Reading RAW/PCM...
Encoding AC3 <448kbps> with libAften...
Creating file "ITA.ac3"...
The original audio track has a constant bit depth of 24 bits.
eac3to processing took 38 seconds.
Done.

laz1989

20th July 2015, 17:29

Does not "-core" work?

Nop.Try already.
I have been thinking it s possible to be an error from DirectShow so i changed the permision to nero, nothing.
SO my question is : At that command line input.thd ouput.ac3 , it's working at someone?

Devilman1

22nd July 2015, 15:53

I want to convert PAL aac audio file to 23.976 wav files, but on every file I try I receive this error message:

AAC, 2.0 channels, 48kHz
Decoding with DirectShow (Nero Audio Decoder 2)...
Getting "Nero Audio Decoder 2" instance failed.
Aborted at file position 262144.

I extracted the AAC audio file using ffmpeg from a .mp4 file.

What does this mean? Is a NeroAacDec error or are the files wrong? They play fine in Vlc.

TIA

Music Fan

22nd July 2015, 15:59

@ laz1989 : you can extract the ac3 core with TSMuxer.

tebasuna51

22nd July 2015, 17:25

I extracted the AAC audio file using ffmpeg from a .mp4 file...

If you have NeroAacDec.exe (free) you can decode the mp4 audio to wav.
Also you can decode to wav, instead extract, with ffmpeg.

After you can use the wav with eac3to to do the 25 -> 23.976 conversion.

To decode aac with eac3to you need Nero7+plugins (not free) installed.

Nebudchanezzer

23rd July 2015, 10:58

Nop.Try already.
I have been thinking it s possible to be an error from DirectShow so i changed the permision to nero, nothing.
SO my question is : At that command line input.thd ouput.ac3 , it's working at someone?

For "-core" to work with TrueHD you have to use it when demuxing the Blu-ray, if you use eac3to to demux to .thd you lose the core as eac3to discards it when demuxing.

The commandline would look something
like this: eac3to path/to/originalvideofile.m2ts 2: path/to/extractedcore.ac3 - core

LigH

23rd July 2015, 12:12

^ omitting the space between "-" and "core".

Thunderbolt8

23rd July 2015, 13:59

there hasnt been any activity in the dcadec department on github for 2 months now. can we conclude from that the development of the decoder is finished and everything is working?

hello_hello

24th July 2015, 05:02

Nop.Try already.
I have been thinking it s possible to be an error from DirectShow so i changed the permision to nero, nothing.
SO my question is : At that command line input.thd ouput.ac3 , it's working at someone?

The way I understand TrueHD (someone correct me if I'm wrong) there is no "core" as there is with DTS-HD. Even though it only appears as a single audio stream, there's two independent streams, the TrueHD audio and the fall-back, lossy AC3. Which you extract appears to depend on the output extension.

The -core parameter only applies to DTS-HD, according to this:
https://en.wikibooks.org/wiki/Eac3to/How_to_Use#Command_Line_Syntax

I don't use eac3to via the command line much. I tend to use the HD Streams Extractor built into MeGUI instead (or there's a standalone version here (http://forum.doom9.org/showthread.php?p=1719399#post1719399)). But I tried a few extractions and checked the command line MeGUI was using. The same TrueHD+AC3 stream was selected each time.

When extracting both streams as a single file with a thd+ac3 extension:
"C:\Program Files\MeGUI\tools\eac3to\eac3to.exe" "E:\Video\" 1) 3:"D:\F1_T3_Audio - English.thd+ac3" -progressnumbers

TrueHD only:
"C:\Program Files\MeGUI\tools\eac3to\eac3to.exe" "E:\Video\" 1) 3:"D:\F1_T3_Audio - English.thd" -progressnumbers

AC3 only:
"C:\Program Files\MeGUI\tools\eac3to\eac3to.exe" "E:\Video\" 1) 3:"D:\F1_T3_Audio - English.ac3" -progressnumbers

Or when opening the m2ts file directly, rather than let the HD Streams Extractor open the whole disc and find the appropriate mpls file, or whatever it does.

"C:\Program Files\MeGUI\tools\eac3to\eac3to.exe" "E:\Video\BDMV\STREAM\00007.m2ts" 3:"D:\T3_Audio - English.ac3" -progressnumbers

eac3to v3.29
command line: "C:\Program Files\MeGUI\tools\eac3to\eac3to.exe" "E:\Video\BDMV\STREAM\00007.m2ts" 3:"D:\T3_Audio - English.ac3" -progressnumbers
------------------------------------------------------------------------------
M2TS, 1 video track, 3 audio tracks, 1:54:39, 50i
1: Chapters, 21 chapters
2: h264/AVC, 1080i50 (16:9)
3: TrueHD/AC3, English, 5.0 channels, 96kHz
(embedded: AC3, 5.0 channels, 640kbps, 48kHz)
4: RAW/PCM, English, 2.0 channels, 16 bits, 48kHz
5: AC3, English, 2.0 channels, 224kbps, 48kHz
[a03] Extracting audio track number 3...
[a03] Extracting AC3 stream...
[a03] Creating file "D:\T3_Audio - English.ac3"...
Video track 2 contains 171972 frames.
eac3to processing took 7 minutes, 31 seconds.
Done.

When I tried each extension, the thd+ac3 file was 5.7GB, the thd file was 5.2GB and the AC3 was 525MB, so that seems right.

Hopefully the info above will help you out.

turab

24th July 2015, 22:26

There is this DTS-ES Matrix track that I want to encode to AAC, but I want to know if it's possible to preserve the channel information. Does AAC even support a 6.1 channel configuration?

tebasuna51

25th July 2015, 11:19

@turab
Yes, AAC support 6.1 channel configuration, but a DTS-ES Matrix have only 5.1 discrete channels, the Back Center channel is mixed in surround channels.

AFAIK AAC headers don't have any flag to inform the player about that.
But I think than is not necesary, you can recode your DTS to a 5.1 AAC and, if you have a 5.1 audio speakers you can listen the Back Center like a fantom channel, if you have a 6.1 audio speakers your receiver/amplifier maybe can extract the Back Center channel for you.

There are a option, not recommended, to convert a 6.1 Matrix in 6.1 discrete channels:
1) Decode 6.1 Matrix to 6 wavs with eac3to
2) Use SL and SR wavs to create a stereo wav (with Sox, WaveWizard or any audio editor like Audacity)
3) Use CenterCutGUI (http://forums.virtualdub.org/index.php?&act=ST&f=21&t=12627&st=0) to create 3 channels
4) Make a 6.1 wav replacing SL/SR with the 3 new channels and encode to AAC

heerschop

25th July 2015, 14:28

@turab
There are a option, not recommended, to convert a 6.1 Matrix in 6.1 discrete channels:
1) Decode 6.1 Matrix to 6 wavs with eac3to
2) Use SL and SR wavs to create a stereo wav (with Sox, WaveWizard or any audio editor like Audacity)
3) Use CenterCutGUI (http://forums.virtualdub.org/index.php?&act=ST&f=21&t=12627&st=0) to create 3 channels
4) Make a 6.1 wav replacing SL/SR with the 3 new channels and encode to AAC

With CenterCut I have created a center.wav and a sides.wav from the combined stereo SL-SR.wav.
- Do you use the center.wav as the center back channel?
- How do you create the wavs for replacing the SL and SR channel? Is this accomplished by converting the stereo center.wav to a center-left.wav and center-right.wav?

greetz

Nebudchanezzer

25th July 2015, 16:59

^ omitting the space between "-" and "core".

True, thats how it goes sometimes using a android-pad to write on. :p

tebasuna51

25th July 2015, 17:38

With CenterCut I have created a center.wav and a sides.wav from the combined stereo SL-SR.wav.
- Do you use the center.wav as the center back channel?
Yes, center.wav is now BC.wav
- How do you create the wavs for replacing the SL and SR channel? Is this accomplished by converting the stereo center.wav to a center-left.wav and center-right.wav?
Nope, use eac3to to split sides.wav to wavs and rename the outputs FL-FR to SL-SR.

turab

25th July 2015, 19:48

Mike

26th July 2015, 00:04

ndjamena

26th July 2015, 01:10

Bitrate is irrelevant. Audio is decoded to PCM before being passed to an encoder, which has a far higher bitrate than any lossy codec.

LigH

26th July 2015, 06:23

But you will not raise quality by raising bitrate. What is lost in the original, can't be restored in the copy.

Smithy

26th July 2015, 08:02

Terminator 2 Judgment Day Skynet Edition 1991 Blu-ray 1080p EUR VC-1 DTS-HD MA

eac3to v3.28 (arcsoft 1.1.0.0)

M2TS, 2 video tracks, 9 audio tracks, 19 subtitle tracks, 2:17:19, 24p /1.001
6: DTS Master Audio, German, 7.1 channels, 24 bits, 48kHz
(core: DTS, 5.1 channels, 1509kbps, 48kHz)
[a06] Extracting audio track number 6...
[a06] Decoding with ArcSoft DTS Decoder...
[a06] Writing WAVs...
[a06] Skipping identical DTS frames (seamless branching)...
[a06] Original audio track: max 24 bits, average 16 bits, most common 16 bits.
[a06] Audio overlaps for 9ms at playtime 0:18:31. <WARNING>
[a06] Audio overlaps for 5ms at playtime 0:39:24. <WARNING>
[a06] Audio overlaps for 8ms at playtime 0:39:42. <WARNING>
[a06] Audio overlaps for 6ms at playtime 1:04:51. <WARNING>
[a06] Audio overlaps for 11ms at playtime 1:07:11. <WARNING>
[a06] Audio overlaps for 8ms at playtime 1:08:47. <WARNING>
[a06] Audio overlaps for 7ms at playtime 1:12:08. <WARNING>
[a06] Audio overlaps for 5ms at playtime 1:21:17. <WARNING>
[a06] Audio overlaps for 12ms at playtime 1:34:04. <WARNING>
[a06] Audio overlaps for 10ms at playtime 1:56:49. <WARNING>
[a06] Audio overlaps for 11ms at playtime 2:01:59. <WARNING>
[a06] Audio overlaps for 8ms at playtime 2:05:06. <WARNING>
[a06] Audio overlaps for 9ms at playtime 2:11:54. <WARNING>
[a06] Starting 2nd pass...
[a06] Extracting audio track number 6...
[a06] Decoding with ArcSoft DTS Decoder...
[a06] Writing WAVs...
[a06] Realizing RAW/PCM gaps...
[a06] Skipping identical DTS frames (seamless branching)...
[a06] Processed audio track: max 24 bits, average 16 bits, most common 16 bits.

eac3to v3.29 (dcadec)

M2TS, 2 video tracks, 9 audio tracks, 19 subtitle tracks, 2:17:19, 24p /1.001
6: DTS Master Audio, German, 7.1 channels, 24 bits, 48kHz
(core: DTS, 5.1 channels, 1509kbps, 48kHz)
[a06] dts, 48000, 7.1
[a06] Extracting audio track number 6...
[a06] Decoding with libDcaDec DTS Decoder...
[a06] Writing WAVs...
[a06] The libDcaDec DTS Decoder reported the error "Bitstream navigation error" while decoding. <ERROR>
Aborted at file position 16039026688. <ERROR>

Smithy

26th July 2015, 08:59

hello friends I'm here with a doubt ..
I have a 384kbps audio to and can convert to 640kbps

It is allowed to convert audio unless kbps kbps for more ...

Or it can only be converted and is allowed to convert more kbps audio for less ...

thank you

But you will not raise quality by raising bitrate. What is lost in the original, can't be restored in the copy.

thats right in theory,
but eac3to/libav ac3 encoder has wrong bandwidth in lower Bitrates for 5.1 like 384 (14 kHz) / 448 (16 kHz) vs Studio AC3 384 (18 kHz) / 448 (20 kHz)

To Save all Frequencies (no cutoff) from Source AC3 to Reencode AC3 with eac3to (libav), the min. Bitrate for 384/448 kbps is 576 kbps @ 5.1,
but 640 kbps are better choise because lossy Encode from lossy Source.
A Speedup for AC3 5.1 384 raise Frequencies near 20 kHz, so u need more Bitrate/Bandwidth for Reencode.
........
Better use Surcode for AC3 Encoder for lower Bitrates,
or AftenGui and EncWAVtoAC3 have bandwith Option from -2 to 60 (5.1 384 kbps 18kHz = 40 / 5.1 448 kbps 20kHz = 48)

LigH

26th July 2015, 11:01

To not lose quality, preferably don't recode (if the source format is supported by the target device). If you convert between different formats (e.g. multichannel AAC to AC3), you may of course use different bitrates because the codecs have different efficiency.

tebasuna51

26th July 2015, 11:57

I was thinking that maybe DTS-ES streams have some side information that's needed for matrix decoding that would get lost in the process.
To matrix decode SL-SR to SL'-BC-SR' you don't need a special side info.
The common parts between SL-SR are extracted to BC channel and elimitated from original SL-SR to output a new pair SL'-SR'.

Only DTS-ES 6.1 discrete have info to do a better channel separation:
http://www.avsforum.com/forum/90-receivers-amps-processors/435592-what-s-difference-between-dts-6-1-matrix-regular-dts-6-1-sound.html#post4224284

Music Fan

26th July 2015, 13:02

To matrix decode SL-SR to SL'-BC-SR' you don't need a special side info.
The common parts between SL-SR are extracted to BC channel and elimitated from original SL-SR to output a new pair SL'-SR'.
In this case, what's the difference between 5.1 and 6.1 matrix mix ? Because with a 6.1 (or 7.1) receiver, both can be converted to 6.1 (or 7.1).

tebasuna51

26th July 2015, 13:39

thats right in theory,
but eac3to/libav ac3 encoder has wrong bandwidth in lower Bitrates for 5.1 like 384 (14 kHz) / 448 (16 kHz) vs Studio AC3 384 (18 kHz) / 448 (20 kHz)

To Save all Frequencies (no cutoff) from Source AC3 to Reencode AC3 with eac3to (libav), the min. Bitrate for 384/448 kbps is 576 kbps @ 5.1,
but 640 kbps are better choise because lossy Encode from lossy Source.
A Speedup for AC3 5.1 384 raise Frequencies near 20 kHz, so u need more Bitrate/Bandwidth for Reencode.
........
Better use Surcode for AC3 Encoder for lower Bitrates,
or AftenGui and EncWAVtoAC3 have bandwith Option from -2 to 60 (5.1 384 kbps 18kHz = 40 / 5.1 448 kbps 20kHz = 48)

1) Of course if you need a re-encode because a speedup operation you can use, at your choice, higer bitrate output. But remember than speedup is a lossy operation and you lose quality always.

2) Of course if you own a commercial certified encoder maybe the output is better than use free AC3 encoders. Thats can't be discussed here.

3) But remember than quality is not only bandwith, at same bitrate you can choice between lose bandwith or lose precission.

4) I make a test encoding a Test.waw 5.1 48 KHz with different options:
Test-Aften-w40-384.ac3 (18 KHz)
Test-Aften-w48-448.ac3 (20 KHz)
Test-eac3to-384.ac3 (14 KHz)
Test-eac3to-448.ac3 (16 KHz)
Test-ffmpeg-384.ac3 (18 KHz)
Test-ffmpeg-448.ac3 (20 KHz)
Test-SoftEncode-384.ac3 (18 KHz, default like Studio AC3)
Test-SoftEncode-448.ac3 (20 KHz, default like Studio AC3)

I used spek to see bandwith, I upload the images here: https://www.sendspace.com/file/egd7tu

5) Remember than eac3to can use the external encoder Aften to override the default parameters used with eac3to:

eac3to Test.wav stdout.wav | Aften -b 448 -w 48 - Test-Aften-w48-448.ac3

6) Now ffmpeg is the free AC3 recommended encoder.

tebasuna51

26th July 2015, 13:58

In this case, what's the difference between 5.1 and 6.1 matrix mix ? Because with a 6.1 (or 7.1) receiver, both can be converted to 6.1 (or 7.1).

Only commercial questions.

To obtain a full surround (plane) audio image for a listener with only two ears 5.1 speakers is more than enough. Systems with 6.1 or 7.1 speakers only want gain more money.

Do you have a ear in the nape? Your ears only listen a mix SL/BC and SR/BC or SL/BL and SR/BR.

Smithy

26th July 2015, 16:41

3) But remember than quality is not only bandwith, at same bitrate you can choice between lose bandwith or lose precission.

4) I make a test encoding a Test.waw 5.1 48 KHz with different options:
Test-Aften-w40-384.ac3 (18 KHz)
Test-Aften-w48-448.ac3 (20 KHz)
Test-eac3to-384.ac3 (14 KHz)
Test-eac3to-448.ac3 (16 KHz)
Test-ffmpeg-384.ac3 (18 KHz)
Test-ffmpeg-448.ac3 (20 KHz)
Test-SoftEncode-384.ac3 (18 KHz, default like Studio AC3)
Test-SoftEncode-448.ac3 (20 KHz, default like Studio AC3)

I used spek to see bandwith, I upload the images here: https://www.sendspace.com/file/egd7tu

1) Of course, example for Precission 5.1 AC3 640 Kbps use Bandwidth @ 48 (20 kHz), too.
Because it don't need more Bandwidth. or better use Bandwith near the Source Frequencies, maybe 18kHz = 40 or 16 kHz = 32 or whatever.
Eac3to/libav use Bandwidth @ 60 (24kHz) for 5.1 AC3 640 Kbps

2) Aften looks best to the Source but SoftEncode looks Crapy ! ;)

Thunderbolt8

26th July 2015, 20:07

is there a way to losslessly change wave/pcm files from 176kHz to flac? when I use the switches -override and -192000 nothing happens, the output flac file still has a sample rate of 176kHz

I can use -ResampleTo192000 but then I get the message "Reducing depth from 64 to 24 bits..." so I dont know if the outcome can still be considered lossless.

LigH

26th July 2015, 20:20

Keiyakusha

26th July 2015, 23:39

Thunderbolt8
It will not be lossless. It is similar to converting pcm to MP3 then to FLAC (but far less destructive) where result is a lossless format that contains data that is no longer lossless. And btw, if you started with 16bit pcm, your result will not only be lossy, but an upscale too (in terms of bitdepth, not only sample count)
That said, I have no idea whether flac supports 176kHz, but I don't really see why it wouldn't. If for some reason it does not have support for it, you better use a different format that can handle it.

hello_hello

27th July 2015, 05:08

According to the info here, the maximum bitdepth supported by flac is 32 bit. https://xiph.org/flac/faq.html#general__samples
It also states: FLAC supports linear sample rates from 1Hz - 655350Hz in 1Hz increments

Only I couldn't make a 32 bit flac file no matter what I did. I tried the command line and several GUIs and the best I could manage was an error message stating 32 bits per sample is unsupported.
Creating a 176kHz wave file was easy. Creating a 176kHz, 64 bit (float) wave file wasn't much harder (adding -full to the command line):

eac3to v3.29
command line: "C:\Program Files\MeGUI\tools\eac3to\eac3to.exe" "E:\test.mkv" 2:"D:\T2_Audio - English.wav" -full -resampleTo176400 -progressnumbers
------------------------------------------------------------------------------
MKV, 1 video track, 1 audio track, 0:01:18, 24p /1.001
1: h264/AVC, English, 928x696 24p /1.001 (4:3)
2: AC3, English, 2.0 channels, 192kbps, 48kHz, dialnorm: -27dB
[a02] ac3, 48000, 2.0
[a02] Extracting audio track number 2...
[a02] Removing AC3 dialog normalization...
[a02] Decoding with libav/ffmpeg...
[a02] Resampling to 176.4kHz...
[a02] Writing WAV...
[a02] Creating file "D:\T2_Audio - English.wav"...
Video track 1 contains 1874 frames.
eac3to processing took 5 seconds.
Done.

But as soon as you tell eac3to to output a flac file (I tried different sample rates and it doesn't make any difference):

eac3to v3.29
command line: "C:\Program Files\MeGUI\tools\eac3to\eac3to.exe" "E:\test.mkv" 2:"D:\T2_Audio - English.flac" -full -resampleTo176400 -progressnumbers
------------------------------------------------------------------------------
MKV, 1 video track, 1 audio track, 0:01:18, 24p /1.001
1: h264/AVC, English, 928x696 24p /1.001 (4:3)
2: AC3, English, 2.0 channels, 192kbps, 48kHz, dialnorm: -27dB
[a02] ac3, 48000, 2.0
[a02] Extracting audio track number 2...
[a02] Removing AC3 dialog normalization...
[a02] Decoding with libav/ffmpeg...
[a02] Resampling to 176.4kHz...
[a02] Reducing depth from 64 to 24 bits...
[a02] Encoding FLAC with libFlac...
[a02] Creating file "D:\T2_Audio - English.flac"...
Video track 1 contains 1874 frames.
eac3to processing took 14 seconds.
Done.

Reducing the bitdepth to something flac will play with makes sense, but is there any way to encode a 32 bit flac file as the flac help documents suggests it can?

LigH

27th July 2015, 08:40

FLAC may be able to support up to 32 bit integer resolution by specification. But eac3to may limit the internal resolution to a sane amount of 24 bit:

Most PCM audio streams may have only 16 or at most 24 bit per sample integer resolution. If you have a lossy format based on frequency spectrum subbands, you will usually have encoded 32-bit floating point values, which have a mantissa precision of 24 bit (see IEEE floating point (https://en.wikipedia.org/wiki/IEEE_floating_point) specs regarding "Single Precision Float"). Even if eac3to converts audio to "Double Precision Float" (64 bit overall, 53 bit mantissa), the original samples still had at most 24 bit precision (rather less in less-than-maximum-volume scenes), therefore it doesn't make sense to waste more than 24 bits after any conversion.

I doubt you will ever get your hands on PCM samples with true 32 bit integer resolution.

madshi

27th July 2015, 09:14

Terminator 2 Judgment Day Skynet Edition 1991 Blu-ray 1080p EUR VC-1 DTS-HD MA

eac3to v3.29 (dcadec)

M2TS, 2 video tracks, 9 audio tracks, 19 subtitle tracks, 2:17:19, 24p /1.001
6: DTS Master Audio, German, 7.1 channels, 24 bits, 48kHz
(core: DTS, 5.1 channels, 1509kbps, 48kHz)
[a06] dts, 48000, 7.1
[a06] Extracting audio track number 6...
[a06] Decoding with libDcaDec DTS Decoder...
[a06] Writing WAVs...
[a06] The libDcaDec DTS Decoder reported the error "Bitstream navigation error" while decoding. <ERROR>
Aborted at file position 16039026688. <ERROR>
Can you provide a small sample with which I could reproduce the issue? Then I can report this to the dcadec developer.

Smithy

27th July 2015, 10:07

Can you provide a small sample with which I could reproduce the issue? Then I can report this to the dcadec developer.

maybe, i will find and check the runtime of aborted position.

the demuxxed dtshd has other file aborted position. ^^

eac3to v3.29

DTS Master Audio, 7.1 channels, 24 bits, 48kHz
(core: DTS, 5.1 channels, 1509kbps, 48kHz)
dts, 48000, 7.1
Decoding with libDcaDec DTS Decoder...
Writing WAV...
Creating file "V:\00018.mpls_6ger.dtshd_.wav"...
The libDcaDec DTS Decoder reported the error "Bitstream navigation error" while decoding. <ERROR>
Aborted at file position 1368129536. <ERROR>

Thunderbolt8

27th July 2015, 10:14

I don't really understand your intentions ... FLAC is a lossless compressor for integer PCM samples without changing the attributes as long as they are supported. If it gets 176 kHz PCM as input, why should the FLAC compressed result have any other sampling rate than 176 kHz? There should be no reason that FLAC would support 192 kHz, but not 176 kHz.

If you wanted to resample 176 kHz to 192 kHz, this resampling won't be lossless. There will probably be a conversion using floating point values intermediately.
I want to concert a DSD (.DFF) audio file losslessly to Flac, because Winamp cant play DSD and the wasapi Plugin cannot play flac files with 176 kHz (only 96 and 192; also no 32-bit flac files; and no, i dont want to change my audio player)

madshi

27th July 2015, 10:15

maybe, i will find and check the runtime of aborted position.
If all else fails, you can encrypt and upload the whole DTS file and PM me the download address. I can then cut a sample for the dcadec dev.

nevcairiel

27th July 2015, 10:24

I want to concert a DSD (.DFF) audio file losslessly to Flac, because Winamp cant play DSD and the wasapi Plugin cannot play flac files with 176 kHz (only 96 and 192; also no 32-bit flac files; and no, i dont want to change my audio player)

You cannot convert DSD to FLAC lossless. There is always going to be a loss when converting DSD to PCM, or vice-versa.

Smithy

27th July 2015, 10:24

If all else fails, you can encrypt and upload the whole DTS file and PM me the download address. I can then cut a sample for the dcadec dev.

i found the position and here is 1 min sample.
http://workupload.com/file/5ppYHVxe

sneaker_ger

27th July 2015, 11:17

FLAC may be able to support up to 32 bit integer resolution by specification. But eac3to may limit the internal resolution to a sane amount of 24 bit:
I think the libflac encoder eac3to uses is limited to 24 bit in the first place. Does an alternative encoder to that even exist?
But as you say: it's probably that way because it's sane.

madshi

27th July 2015, 11:23

i found the position and here is 1 min sample.
http://workupload.com/file/5ppYHVxe
Thanks. I've reported it to the dcadec dev.

LigH

27th July 2015, 11:39

I think the libflac encoder eac3to uses is limited to 24 bit in the first place. Does an alternative encoder to that even exist?

Any independent flac.exe or libflac.dll based on official sources:

https://sourceforge.net/projects/flac/
http://www.rarewares.org/lossless.php

sneaker_ger

27th July 2015, 11:41

I meant an alternative encoder that encodes to FLAC format but is not based on libFLAC. (And that supports 32 bit encoding)

LigH

27th July 2015, 11:53

Please excuse the counter-question ... but: Would there be any reason to spend any time on re-programming an OpenSource software with a rather tolerant free license?

I don't know any source adoption as freely available as the reference implementation by Xiph.org (https://xiph.org/flac/index.html) yet.

nevcairiel

27th July 2015, 12:24

Would there be any reason to spend any time on re-programming an OpenSource software with a rather tolerant free license?

Often its a good idea to have independent implementations, as it can drive new ideas and improvements. For FLAC, FFmpeg has an independent decoder and encoder, but it seems limited to 24-bit as well.

hello_hello

27th July 2015, 14:36

FLAC may be able to support up to 32 bit integer resolution by specification. But eac3to may limit the internal resolution to a sane amount of 24 bit....

I doubt you will ever get your hands on PCM samples with true 32 bit integer resolution.

What's the definition of "true 32 bit integer resolution"?
I can make a 32 bit wave file easily enough with Audacity. I think. This is 32 bit integer isn't it?

General
CompleteName : D:\test.wav
Format : Wave
FileSize/String : 12.2 MiB
Duration/String : 9s 59ms
OverallBitRate_Mode/String : Constant
OverallBitRate/String : 11.3 Mbps

Audio
Format : PCM
Format_Settings_Endianness : Little
Format_Settings_Sign : Signed
CodecID : 1
Duration/String : 9s 59ms
BitRate_Mode/String : Constant
BitRate/String : 11.3 Mbps
Channel(s)/String : 2 channels
SamplingRate/String : 176.4 KHz
BitDepth/String : 32 bits
StreamSize/String : 12.2 MiB (100%)

I tried both versions of flac you linked to as well as the version on the flac website, and wherever version foobar2000 is using that doesn't seem to like 32 bit integer either.

http://s28.postimg.org/pbn2c65q5/32_bit.gif

Audacity is the only program I have installed that'll output a 32 bit integer wave file. The other programs such as foobar2000 seem to want to output a 32 bit float wave file.
You're right though, anything over 24 bit for a flac file would definitely be overkill. I was just curious to try it when I read Thunderbolt8's question.

I don't know much about DSD, but according to Wikipedia it's comparable to 20 bit, 96kHz PCM, so a 24 bit flac file should be quite adequate.

LigH

27th July 2015, 15:17

What's the definition of "true 32 bit integer resolution"?
I can make a 32 bit wave file easily enough with Audacity. I think. This is 32 bit integer isn't it?

So you want to convert 24 bit PCM to 32 bit PCM ... You can stuff the 8 lsb with 0-bits. The result still has at most 24 bit precision.

I rather mean: I wonder if there is any hardware recording audio with up to 32 bit precision. But I doubt that there are many 32-bit ADC (analogue-digital convertors) available, as well as I doubt there are many microphones with a sensitivity required to record with 32 bit precision.

IMHO, there are physical and electronical limits which would make audio recording with 32 bit precision very improbable. And even if, the "noise carpet" on any realistic movie set (not in "deaf rooms", not for synthetic sounds) would probably be high enough to return a signal-to-noise ratio even below the 24 bit treshold (don't remember exactly where it was, 120 dB?).

So in most practical cases, 32 bit precision would be an illusion, lying on a big fluffy carpet of noise.

ZMachine95

27th July 2015, 21:03

SeeMoreDigital

27th July 2015, 21:28

I don't know much about DSD, but according to Wikipedia it's comparable to 20 bit, 96kHz PCM, so a 24 bit flac file should be quite adequate.If you're interested, Oppo Digital prefer to transcode DSD 64 (single-rate) to PCM @ 88.2KHz/24-bit.

Mathematically the file size of a DSD 64 stream works out at almost the same file size as an PCM stream @ 88.2KHz/32-bit ;)

Cheers

Groucho2004

27th July 2015, 21:35

I wonder if there is any hardware recording audio with up to 32 bit precision.Even high end audio interfaces max out at -130 dB THD+N, still below 24 bit resolution.

signal-to-noise ratio even below the 24 bit treshold (don't remember exactly where it was, 120 dB?).
20 x log(1/(2^24)) = -144 dB. :D

So in most practical cases, 32 bit precision would be an illusion, lying on a big fluffy carpet of noise.
Yep.

foxyshadis

28th July 2015, 20:39

thats right in theory,
but eac3to/libav ac3 encoder has wrong bandwidth in lower Bitrates for 5.1 like 384 (14 kHz) / 448 (16 kHz) vs Studio AC3 384 (18 kHz) / 448 (20 kHz)

Remember that for every bit you spend on a high frequency you have to spend one less bit on a lower frequency. If you can't hear that frequency, if your speakers can't properly represent it, or if including more high frequencies results in audible distortion across the spectrum, then you're better off severely low-passing. At those bitrates for 5.1, I would lowpass even if eac3to didn't do it for me. (Instead I used newer codecs that can easily handle low rates.)

foxyshadis

28th July 2015, 20:47

I want to concert a DSD (.DFF) audio file losslessly to Flac, because Winamp cant play DSD and the wasapi Plugin cannot play flac files with 176 kHz (only 96 and 192; also no 32-bit flac files; and no, i dont want to change my audio player)

DSD128 is 5.6 MHz, if you have 176kHz then it's already been converted to PCM. Winamp's plugin will never be updated, so you should use software that directly decodes it to 96 or 192kHz instead (even 96 is probably overkill) to eliminate any possibility of loss... but even SSRC conversion will have only the absolute minimum difference, far below anything measurable.

ZMachine95

28th July 2015, 20:55

hello guys and girls, I would like to convert some BDMV's folders. I would like to use eac3to to to get the correct mpls file and send all tracks on ffmpeg stdin and convert.

I have thought about using something like that..

but it doesn't work. If I use only stdout.h264 the video track is piped to ffmpeg and converted.

eac3to J:\BDMV\ 1) stdout.mkv | ffmpeg.exe -hwaccel auto -y -i - -map 0:v:0 -c:v libx265 -crf 20.0 -preset veryfast -map 0:a:0 -c:a:0 libvorbis -b:a:0 192k -map 0:a:1 -c:a:1 libvorbis -b:a:1 192k -map 0:s:0 -c:s:0 copy -map 0:s:1 -c:s:1 copy -map 0:s:2 -c:s:2 copy "H:\output.mkv"

What am I doing wrong? or there is a fast way to do that?... I don't actually have to use only ffmpeg and eac3to..

thanks guys

Someone can help me?

Music Fan

28th July 2015, 21:06

if including more high frequencies results in audible distortion across the spectrum
When and why does it happen ?

LigH

28th July 2015, 23:02

@ ZMachine95:

Not sure why. But maybe MKV is not really a streamable format. It is a container to keep video and audio (etc.) in sync; so it may need to get values in its header up-to-date which are only known after writing the MKV out has finished. Check if it works in two steps (eac3to writing the MKV to disc, then ffmpeg processing it afterwards).

Or wait for people more experienced with eac3to ripping Blu-rays to MKV.

tebasuna51

28th July 2015, 23:17

Someone can help me?
Nope.

eac3to uses Haali to create mkv's with only video, not full mkv's with all tracks, then is useless for you even if work your sintax.

I'm surprised than work with stdout.h264.

DarkSpace

28th July 2015, 23:21

hello guys and girls, I would like to convert some BDMV's folders. I would like to use eac3to to to get the correct mpls file and send all tracks on ffmpeg stdin and convert.

I have thought about using something like that..

eac3to J:\BDMV\ 1) stdout.mkv | ffmpeg.exe -hwaccel auto -y -i - -map 0:v:0 -c:v libx265 -crf 20.0 -preset veryfast -map 0:a:0 -c:a:0 libvorbis -b:a:0 192k -map 0:a:1 -c:a:1 libvorbis -b:a:1 192k -map 0:s:0 -c:s:0 copy -map 0:s:1 -c:s:1 copy -map 0:s:2 -c:s:2 copy "H:\output.mkv"

but it doesn't work. If I use only stdout.h264 the video track is piped to ffmpeg and converted.

What am I doing wrong? or there is a fast way to do that?... I don't actually have to use only ffmpeg and eac3to..

thanks guys

Just so you know, all that eac3to does when it outputs mkv is to mux the video track. No audio, no subtitles, no chapters, just a container and its video track.
I think that should explain your particular problem.

Now, what you could try is to make eac3to join the individual m2ts files into a single m2ts and pipe that to ffmpeg. I have no idea if this works (depends on whether m2ts is streamable), but I rather expect it to. Use something like this:

eac3to 00001.mpls stdout.m2ts | ffmpeg -i - -o output.mkv

Things you'll need to test:

Does stdout.m2ts work as expected?
Can eac3to output joined m2ts files from a playlist file, or do you need to manually input the individual m2ts files?
Is the m2ts format streamable, or does ffmpeg need to seek in the file to properly decode/split it? I guess that it is streamable, but I don't know.

LigH

29th July 2015, 08:22

This may just be a case where eac3to is not the optimal tool.

Smithy

29th July 2015, 19:13

Remember that for every bit you spend on a high frequency you have to spend one less bit on a lower Frequency. If you can't hear that frequency, if your speakers can't properly represent it, or if including more high frequencies results in audible distortion across the spectrum, then you're better off severely low-passing. At those bitrates for 5.1, I would lowpass even if eac3to didn't do it for me. (Instead I used newer codecs that can easily handle low rates.)

Yes of Course, but cut-off Frequencies below lossy core Sources is nogo!
Save max possible Quality for Audio Reencodes is best way and its not a Big Deal to use Higher or Max Bitrates for more bits @ lower Frequencies.
Everyone takes different perception to hear frequencies itself and by Setups.
This is not a question what you can hear or other can or not, because @ eac3to/libav that most people used, have no Control of bandwidth option or lowpass.
AftenGui or wavtoac3enc (don't know ffmpeg) have more Control about bandwidth per Bitrate, bandwidth lowpassfilter, LFE lowpassfilter or Dialnorm.
Before make encode of AC3, a Normalize of -3dB or more is needed, against Clipping that depend on the source.
And lower bitrate/bandwidth Encodes guaranteed more clipping and DC-offset ... check the decoded wavs from reencoded AC3.

Boulder

1st August 2015, 19:27

As we've seen some discussion regarding the 3/1-channel files, can anyone help me to convert such an audio track to a standard 5.1ch track to avoid any playback issues? I think I've seen such an operation somewhere here, but couldn't find it anymore.

Opusenc just gives me this:

WARNING: Unknown WAV surround channel mask: 263
Blindly mapping speakers using default SMPTE/ITU ordering.
Encoding using libopus 1.1.1-beta-24-g66611f1-dirty (audio)
-----------------------------------------------------
Input: 48kHz 4 channels
Output: 4 channels (4 coupled)
20ms packets, 240kbit/sec VBR
Preskip: 312

It seems that it's guessing 2 front and 2 surround channels.

Music Fan

1st August 2015, 19:56

As we've seen some discussion regarding the 3/1-channel files, can anyone help me to convert such an audio track to a standard 5.1ch track to avoid any playback issues?
You can maybe create 2 empty waves for the rear channels to accompany your 4 channels.

tebasuna51

1st August 2015, 22:07

...
It seems that it's guessing 2 front and 2 surround channels.

Nope, channel mask 263 is FL,FR,FC,BC (3 front and 1 surround).
You can use sox (eac3to can't do that):

sox 4w310.wav 6w51.wav remix -m 1 2 3 3v0 4v0.7071 4v0.7071

Silent LFE and BC to SL,SR (half volume each).

Boulder

1st August 2015, 22:13

Thanks, I'll use that from now on in those rare cases :)

adhaing

4th August 2015, 06:52

for instance:

eac3to input stdout.w64 | ffmpeg -i - -c:a ac3 -b:a 640k output.ac3

Weird that for direct streaming like this, when
eac3to 6ch-24bit.dtshd stdout.w64 | ffmpeg -i - -c:a ac3 -b:a xxxk
the process would always stop at around time=01:22:46 where the virtual .w64 just exceeded 4GB (of course no actual .w64 generated in this case). Then eac3to wailed with the log
The W64 writer couldn't seek to the header. <ERROR>
Aborted at file position 5103389848. <ERROR>
Decoded either with ArcSoft or DCA, the same results.

However, when I created an intermediate .w64 at first with eac3to (up to 7GB), then fed it into ffmpeg, everything was fine.

I know now ffmpeg itself could properly handle dtshd-ma5.1, but I'm just wondering what's wrong with the direct piping/streaming of the loyally unlimited .w64?

Cheers.

tebasuna51

4th August 2015, 09:58

the process would always stop at around time=01:22:46 where the virtual .w64 just exceeded 4GB (of course no actual .w64 generated in this case). Then eac3to wailed with the log
The W64 writer couldn't seek to the header. <ERROR>
Aborted at file position 5103389848. <ERROR>
...
I know now ffmpeg itself could properly handle dtshd-ma5.1, but I'm just wondering what's wrong with the direct piping/streaming of the loyally unlimited .w64?

There are two problems like you can see in my last post (http://forum.doom9.org/showthread.php?p=1726046#post1726046) about that:

1) When eac3to begin to write the pipe output (stdout.w64) don't know the whole length of the data and put a temporal header with a size of 4GB (like put with a stdout.wav) and ffmpeg stop to encode at this size (the size of a wav 5.1 24 bits 48 KHz 01:22:46).

This problem can be solved putting a temporal bigger size (for instance 1TB). The fields for sizes in w64 have 64 bits, just for solve the 4GB wav limit because the equivalents fields have only 32 bits and don't support values greater 4GB.

2) When eac3to finish to decode know the correct data length, and try to rewrite the w64 header with the correct value, if the output is a w64 file the process finish ok, but can't rewrite the piped output and abort with the
The W64 writer couldn't seek to the header. <ERROR>
Aborted at file position 5103389848. <ERROR>

Even if the size is less than 4GB this eac3to abort can cause a ffmpeg error because the last audio data can be incomplete
[pcm_s24le @ 0000000002d19700] Invalid PCM packet, data has size 8 but at least a size of 18 was expected
Error while decoding stream #0:0: Invalid data found when processing input

The problem can be solved if eac3to don't try to rewite the piped w64 header and don't abort (like don't abort with piped wav).
ffmpeg can stop without errors when finish the piped data, even if the size expected is greater (1 TB) than the received data.

ron spencer

6th August 2015, 02:45

any reason why an Atmos file crashes eac3to...using 3.29

error I get is:

The libav decoder reported error -1094995529 while decoding. I just want to convert to AC3 448

thx

Elegant

11th August 2015, 01:52

If only you could offset by samples...

ZMachine95

11th August 2015, 19:16

Just so you know, all that eac3to does when it outputs mkv is to mux the video track. No audio, no subtitles, no chapters, just a container and its video track.
I think that should explain your particular problem.

Now, what you could try is to make eac3to join the individual m2ts files into a single m2ts and pipe that to ffmpeg. I have no idea if this works (depends on whether m2ts is streamable), but I rather expect it to. Use something like this:

eac3to 00001.mpls stdout.m2ts | ffmpeg -i - -o output.mkv

Things you'll need to test:

Does stdout.m2ts work as expected?
Can eac3to output joined m2ts files from a playlist file, or do you need to manually input the individual m2ts files?
Is the m2ts format streamable, or does ffmpeg need to seek in the file to properly decode/split it? I guess that it is streamable, but I don't know.

thanks man.. i'll give it a try :)

EDIT: does not work... I have tried to use mkvmerge but has no support for pipelining.. I guess the only way is to use mkvmerge and mux locally then use the mkv file as input for ffmpeg

LigH

11th August 2015, 20:01

There are containers which need to work on physical files, to have a chance to write correct header values after the whole file has been processed. Pipes are unable to rewind.

Devrim

13th August 2015, 01:47

When eac3to shows only 1 playlist, is that 100% the correct playlist? (Lets assume the bluray has been ripped properly)

I know some companies throw some fake playlists (changing scenes, stopping halfway) on blurays, does eac3to detect those properly?

Snowknight26

13th August 2015, 15:02

No. It only sorts the playlists by length.

Devrim

13th August 2015, 15:10

No. It only sorts the playlists by length.

But does it detect all playlists correctly? (So in the end, 1 playlist = the correct playlist anyways)

Snowknight26

13th August 2015, 20:28

It'll read the MPLS files and display them (well, any above 30 minutes from what I recall), but it's your job to figure out which one is the correct one, especially if there are hundreds of others of similar durations.

LigH

14th August 2015, 07:21

If there is only one playlist on the disk, where should another fake playlist come from? AFAIK, it is not like DVD Video where the contents of the ISO-9660 and the microUDF file systems may differ, Blu-ray video has only one UDF 2.50 file system, no ISO-9660 compatibility layer for PCs (current PC operating systems can access UDF-only disks with appropriate drivers). There must be at least one valid playlist so that a real consumer Blu-ray player can play the movie correctly. If there is no other, there is no other fake one.

r0lZ

14th August 2015, 08:44

In my experience, there are often several playlists with (exactly or almost) the same content. They are not "fake" playlists. Just dupes. For example, it is not unusual to find a playlist with several languages except Chinese, and another playlist with the same content, but only the Chinese audio and subtitles. Also, on 3DBDs, the same playlist may be present in 2D (without the 3D extensions) and in 3D (with the reference to the MVC stream). But the 3D playlist can be duplicated too, with one playlist containing the references to the 3D-Planes (used to decode the subtitles in 3D), and the other playlist without the 3D-Planes (and therefore "less good", although the MPLS files referenced are exactly identical). And playlists exactly identical are usual too, for a reason I have never understood. In multi-angle BDs, there are often also simple playlists that reference only a single M2TS. That doesn't make sense, since if you play them you see only a short part of the movie. I suppose they are remnants of the abstract layer of the authoring program.

Anyway, there is no rule, and you can't say for sure what is the "best" playlist to use without examining carefully their content and variants.

And I can confirm that when several playlists have the same content (in term of referenced MPLS files) eac3to shows only one of them, but unfortunately not always the "best" playlist. To be sure, you have to display the information of all playlists, one at a time. Or write your own MPLS parser.

tebasuna51

14th August 2015, 09:31

Seems madshi found many samples about the related problem, changelog items:

v3.19
* added support for 3D Blu-Rays (playlists, detection & demuxing)
v3.00
* workaround for movie playlists which want the same m2ts file played twice
v2.85
* fixed: v2.84 sometimes chose wrong m2ts playlist file
v2.66
* when there are 2 similar playlists the one with less chapters is ignored now
v2.59
* added workaround for Blu-Ray playlists with multiple last "invalid" parts
v2.58
* added workaround for Blu-Ray playlists with a last small "invalid" m2ts part
v2.45
* Blu-Ray angles are now reported as separate titles
* duplicate playlists are not listed in the "folder view", anymore

But, of course, maybe there are exceptions not solved.

EDIT:
I read complex workarouds to know the "correct" playlist than a BDplayer uses by default (search the mpls file in use by the OS) but nothing about how found that info in BD data.

Xorp

14th August 2015, 16:51

When I convert TrueHD 7.1 Atmos to FLAC, what happens to the Atmos information? Is it dropped or mixed in?

sneaker_ger

14th August 2015, 17:17

It's not used. There is no free Atmos decoder.

Xorp

14th August 2015, 17:42

What I suspected, thanks

rapscallion

14th August 2015, 22:27

When I convert TrueHD 7.1 Atmos to FLAC, what happens to the Atmos information? Is it dropped or mixed in?
Will conversion/decoding to wavs be done correctly (without Atmos info of course)

I tried it and it completed without errors, however, there's no way I can verify that it's correct.

Stereodude

15th August 2015, 01:26

I tried it and it completed without errors, however, there's no way I can verify that it's correct.
By that standard don't you have the same issue with any conversion it makes? How do you know that non-Atmos conversions are correct?

rapscallion

15th August 2015, 03:37

Because I have unwavering faith in Madshi. However, the latest release of eac3to was prior to the introduction of Atmos.

Boulder

15th August 2015, 05:32

Because I have unwavering faith in Madshi. However, the latest release of eac3to was prior to the introduction of Atmos.One reason for the release of the latest version was to handle Atmos correctly (to ignore it) :)

rapscallion

15th August 2015, 18:03

I guess it would have helped if I had read the change log : )

radigast

22nd August 2015, 19:03

I have 2 questions regarding TrueHD demuxing bugs I am experiencing:

1. Is the .thd+ac3 / .ac3 switch currently broken on TrueHD tracks for eac3to?
2. Is the .thd switch currently working incorrectly by giving the TrueHD file and embedded AC3 "core"?

Specifics:

1. TrueHD demuxing with eac3to 3.29 is throwing some errors and is unable to output any file. I am attempting to demux a TrueHD stream from a BD using the following commands (a log file isn't generated, as the command window simply freezes until I ctrl-c it):
eac3to.exe 00001.mpls 1) 3: 00001.mpls.thd+ac3
eac3to.exe 00001.mpls 1) 3: 00001.mpls.ac3
Both of these commands cause the error:The libav decoder reported error -1094995529 while decoding....which freezes the command window, and yields no output.

2. Using the .thd extension successfully yields a working .thd file (strangely enough, with the embedded 640 kbps AC3 "core"). My understanding is that using the .thd extension is supposed to only give the actual "coreless" .thd file. The command used here is:
eac3to.exe 00001.mpls 1) 3: 00001.mpls.thd

The BD in question has the following structure:M2TS, 1 video track, 1 audio track, 2 subtitle tracks, 1:28:08, 24p /1.001
1: Chapters, 12 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: TrueHD, English, 5.1 channels, 48kHz
4: Subtitle (PGS), English
5: Subtitle (PGS), Spanish

Any thoughts / confirmation / input on this?

sneaker_ger

22nd August 2015, 20:14

radigast

23rd August 2015, 01:12

There have been reports that mighty be related:
http://forum.doom9.org/showpost.php?p=1730781&postcount=13349
http://forum.doom9.org/showpost.php?p=1733150&postcount=13420

I suggest your open a report on madshi's bug tracker about the problem and include a sample file. Without a sample it might be difficult to fix for madshi.
http://bugs.madshi.net/Thanks for the heads-up. I would love to submit a sample. However, eac3to is what I usually use to create samples...which is problematic because it doesn't work for these specific videos. Any ideas what else I can use to make samples?

sneaker_ger

23rd August 2015, 01:16

Try cutting out the first ~50 MB of the respective m2ts using e.g. DGSplit (http://rationalqm.us/dgsplit/dgsplit12.zip). If you can reproduce the problems with this small sample you are good to go. (Not sure if it makes also sense to include the playlist files)

Music Fan

23rd August 2015, 09:24

You can also use TSMuxer to cut or join ts, m2ts, mp4, mov ... (never heard of DGSplit).

tebasuna51

23rd August 2015, 11:59

1) Your 00001.mpls have only one .m2ts?

Use
eac3to "BD_FOLDER\"
to obtain a log than show how many .m2ts have your 00001.mpls.

If there are more than one, load each one with eac3to and verify than the track 2 (m2ts don't have Chapters and now first audio is track 2) have always the same format, for instance:

2: TrueHD/AC3, English, 5.1 channels, 48kHz
(embedded: AC3, 5.1 channels, 640kbps, 48kHz)

eac3to can't join the track if one of them have a different format.

2) Your BD is a correct rip from a original BD or is a downloaded one?
In first case say us the method used to rip the BD to hard disk.
In second case we can't help you and maybe is a corrupt one.

radigast

23rd August 2015, 14:31

The playlist only links to a single .m2ts file; there is no seamless branching.

I split that .m2ts file into 50mb pieces and tested several pieces. I was able to successfully extract the TrueHD stream as both .ac3 and .thd+ac3 for each piece with no errors. However, when I tried on the unsplit .m2ts file (and when also loading via the playlist), I received the same error I had posted before.

Any other ideas / suggestions?

Snowknight26

23rd August 2015, 16:54

If you want to get your hands dirty, you could run Process Monitor to see how far eac3to.exe reads into the file, then you'll have a rough approximation as to where in the file the error occurs.

radigast

24th August 2015, 11:36

If you want to get your hands dirty, you could run Process Monitor to see how far eac3to.exe reads into the file, then you'll have a rough approximation as to where in the file the error occurs.Oh, I want dirty hands. I have only ever used Process Monitor once, though. Help me get these hands dirty, please!

(What sort of filters should I put in place?)

Snowknight26

24th August 2015, 18:35

Something like 'Process is eac3to.exe' and 'Path contains .m2ts' should suffice.

radigast

29th August 2015, 09:13

Finally found some time this week...

I used ProcMon with the exact filters you suggested.

The BD in question has the following streams:
M2TS, 1 video track, 1 audio track, 2 subtitle tracks, 1:28:08, 24p /1.001
1: Chapters, 12 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: TrueHD, English, 5.1 channels, 48kHz
4: Subtitle (PGS), English
5: Subtitle (PGS), Spanish

First, I tried to demux the TrueHD stream as .thd+ac3.
eac3to.exe "J:\BDMV\PLAYLIST\00001.mpls" 1) 3: 00001.mpls.thd+ac3
This immediately produced the same error I mentioned before:The libav decoder reported error -1094995529 while decoding.
The ProcMon log is here: http://pastebin.com/M77XQh7f

Second, I tried to demux the TrueHD stream as .ac3.
eac3to.exe "J:\BDMV\PLAYLIST\00001.mpls" 1) 3: 00001.mpls.ac3
This yielded the same error as above.
The ProcMon log is here: http://pastebin.com/Lc5a2SuH

Again, if I manually cut the sole .m2ts file this playlist refers to into pieces, both commands work fine.

Any ideas?

Snowknight26

29th August 2015, 15:47

Unfortunately your logs don't show any ReadFile operations so we still don't know where exactly in the file the error occurs.

If it matters, that error means "Invalid data found when processing input" though.

Smithy

10th September 2015, 15:24

Any Chance to Decode DD+ / EAC3 @ 7.1 in the next time ?

Smithy

11th September 2015, 22:52

eac3to 3.29

DTS, 5.1 channels, 2:16:09, 755kbps, 48kHz

Arcsoft 1.1.0.0 (Abort @ 99%)

dts, 48000, 5.1
Decoding with ArcSoft DTS Decoder...
Patching bitdepth to 24 bits...
Writing WAVs...
The ArcSoft DTS Decoder reported an error while decoding. <ERROR>
Aborted at file position 760479744. <ERROR>

DcaDec (Abort @ 99%)

dts, 48000, 5.1
Decoding with libDcaDec DTS Decoder...
Patching bitdepth to 24 bits...
Writing WAVs...
The libDcaDec DTS Decoder reported the error "Invalid bitstream format" while decoding. <ERROR>
Aborted at file position 760479744. <ERROR>

Libav/FFMpeg (Abort @ 99%)

dts, 48000, 5.1
Patching bitdepth to 24 bits...
Decoding with libav/ffmpeg...
Writing WAVs...
[libav] LFEScaleIndex larger than 127 <WARNING>
[libav] If you want to help, upload a sample of this file to ftp://upload.ffmpeg.org/MPlayer/incoming/ and contact the ffmpeg-devel mailing list. <WARNING>
[libav] error decoding block <WARNING>
The libav decoder reported error -1094995529 while decoding. <ERROR>
Aborted at file position 760479744. <ERROR>

Sonic 4.3.0.169 (100% OK)

dts, 48000, 5.1
Patching bitdepth to 24 bits...
Decoding with DirectShow (Sonic Audio Decoder)...
DirectShow reports 5.1 channels, 24 bits, 48kHz
Writing WAVS...
Done.

DTS Aborted Sample (10s)
http://workupload.com/file/mp9Z1lJw

tebasuna51

12th September 2015, 01:05

Decoding your sample from frame 0 to 232 and from frame 234 to end work fine always with all decoders.

The frame 233 is corrupt and some decoders abort (ArcSoft, libav, dcadec) or output garbage (NicAudio).

I don't have Sonic to test, but check yourself if decoding your 10s sample there are a click (garbage) at 2,5 s

BTW eac3to can't do nothig to recover corrupt frames or change the decoders behaviour.

Smithy

12th September 2015, 01:45

the bitstream results in No Sound during this frame/runtime,
but the decoded file with sonic is fine @ this frame. ^^

DTS Decode (Sonic) Sample (10s .wav)
http://workupload.com/file/uh342a1s

tebasuna51

12th September 2015, 15:50

Well seems the Sonic decoder do the trick.

I tested some other decoders, to resume:
- Abort: ArcSoft, dcadec and libav
- Big click: Nicaudio (AviSynth), Foobar2000, Tranzcode and Valdec (ac3filter_tools_0_31b)

hello_hello

12th September 2015, 16:57

I tested some other decoders, to resume:
- Abort: ArcSoft, dcadec and libav
- Big click: Nicaudio (AviSynth), Foobar2000, Tranzcode and Valdec (ac3filter_tools_0_31b)

On the directshow front:
LavAudio decodes it.
ffdshow and libdts doesn't (big click).
ffdshow and libavcodec is fine.

Smithy

12th September 2015, 17:49

Yes LavAudio decodes playd fine, too.

Elegant

24th September 2015, 15:11

I've been noticing that when I create FLAC files I keep getting "VALID_BITS: 00", any chance on getting that to match the actual bit depth of the audio file? Or is this an issue with libFLAC?

r0lZ

26th September 2015, 10:33

I have noticed a problem with the AAC/M4A files generated by eac3to, when they are muxed with mkvmerge.

When I use eac3to to convert an audio track to AAC, it produces the AAC track within a M4A container. That M4A file can be muxed directly with the video track with MkvMerge. But often, the sound is choppy when I play the resulting MKV on my Samsung TV. (The same file can be played without problem with all software players I have tried so far.)

If I extract the AAC track from the M4A and then mux it with MkvMerge, there is no problem any more. The sound is perfect, including when it is played with my TV.

If that matters, the input files are a PCM WAV mono at 48 KHz, and a DTS 5.1 at 48 KHz 1509 Kbps. They are standard files, and there is no warning during the conversions.

To retrieve the AAC track from the M4A container, I use MkvMerge to mux the M4A to MKA, and MkvExtract to extract the AAC from the MKA. I have also used ffmpeg with "-acodec copy" with the same result: the AAC itself can always be successfully muxed.

I wonder several things:

- Is it a known bug of eac3to (or MkvMerge) ?

- Why eac3to creates the M4A container and not an elementary AAC stream ?

- Is it possible to force eac3to to create the AAC stream without the M4A container? (Specifying "output.aac" instead of "output.m4a" is accepted by eac3to, but it produces a M4A file anyway.)

Someone else has noticed similar problems?

Thanks in advance for any pointer!

Music Fan

26th September 2015, 11:47

If you analyze both mkv's with MediaInfo, are there differences in the audio descriptive ? MediaInfo is sometimes wrong but it may help.

tebasuna51

26th September 2015, 11:50

- Is it a known bug of eac3to (or MkvMerge) ?
eac3to work with NeroAacEnc.exe in the same folder. I only now this problem:
"- NeroAacEnc crash sometimes when piped directly by eac3to, work always when use the OS pipe.
Workaround: eac3to input stdout.wav | NeroAacEnc -q 0.5 -ignorelength -if - -of output.m4a"

But I never read a problem like you say: finish OK and " sound is choppy".

MkvMerge need know when a AAC is HE, but NeroAacEnc output always AAC-LC with quality greater 0.35, the default quality with eac3to is 0.5

MkvMerge, AFAIK, read m4a metadata to correct delay but store only the AAC streams in mkv. Don't have sense for me than extract the AAC and after remuxed change anything.

I read than some players can't play mono or 5.1 correctly (stereo always ok), but your player seems work with the AAC.

- Why eac3to creates the M4A container and not an elementary AAC stream ?
NeroAacEnc always output AAC in mp4 container (m4a)

- Is it possible to force eac3to to create the AAC stream without the M4A container? (Specifying "output.aac" instead of "output.m4a" is accepted by eac3to, but it produces a M4A file anyway.)
Not possible with NeroAacEnc, but you can use other encoders (if you have the required soft not included in eac3to) to output AAC with standard ADTS headers. For instance:

eac3to input stdout.wav | qaac -V 99 --ignorelength --adts --no-delay -o output.aac -

Someone else has noticed similar problems?
AFAIK not until now.

EDIT:
When Mkvmerge mux a m4a from NeroAacEnc always correct the delay cutting the first frames and add a +9ms of delay to track.
If AAC is extracted and after remuxed the delay +9ms dissapear.
For me that is the only difference between mkv's, maybe your player have problems with the delay.

Music Fan

26th September 2015, 12:53

eac3to input | qaac -V 99 --ignorelength --adts --no-delay -o output.aac -
Don't forget stdout.wav after input.

Don't have sense for me than extract the AAC and after remuxed change anything.
I already had the same kind of problem with videos : when I open a TS including interlaced H264 in MKVmerge, it creates a file considered as VFR by MediaInfo (while it's CFR).
But if I demux the video with TSMuxer then open the ES in MKVmerge, the video is correctly considered as CFR by MediaInfo (as the original TS, there is no error in the TS stream).

It seems MKVmerge has problems with some containers or headers.

szabi

26th September 2015, 21:01

Hi

I tried to extract AC3 from THD audio.
However eac3to always encoding instead of extraction.
What can I do to solve it?

bye
szabi

LigH

26th September 2015, 21:19

Start with posting your complete command line.

szabi

27th September 2015, 07:37

Hi

It is the log file:
eac3to v3.29
d:\eac\eac3to.exe" "E:\my video\movie.mkv" 2: "E:\my video\movie2eng.ac3"
analyze: 1%
.
.
analyze: 99%
analyze: 100%
MKV, 1 video track, 2 audio tracks, 3 subtitle tracks, 2:00:23, 24p /1.001
1: h264/AVC, 1080p24 /1.001 (16:9)
2: TrueHD (Atmos), English, 7.1 channels, 48kHz
.
.
a02 thd, 48000, 7.1
a02 AC3 encoding doesn't support back channels. Will mix them into the surround.
a02 Extracting audio track number 2...
a02 Decoding with libav/ffmpeg...
a02 Mixing surround channels...
a02 Remapping channels...
a02 Encoding AC3 <640kbps> with libAften...
a02 Creating file "E:\my video\movie.mkv_2eng.ac3"...
process: 1%
.
.

It is the first time I can not extract AC3.

bye
szabi

r0lZ

27th September 2015, 08:48

Thanks for your reply, tebasuna51.
MkvMerge need know when a AAC is HE, but NeroAacEnc output always AAC-LC with quality greater 0.35, the default quality with eac3to is 0.5
Do you mean that the encoding type changes when the quality is less than 0.35? Anyway, the advantage of the M4A container is that it has the correct info, and it should not be necessary to specify the HE flag to MkvMerge. BTW, I did my test with the default quality 0.5. Also, I've tried to change the flag in MkvMerge, for the M4A and AAC streams, but that doesn't change anything. The AAC sound is always perfect, and the M4A stream is always choppy.

Don't have sense for me than extract the AAC and after remuxed change anything.
It's also something I don't understand. It's why I have suspected a bug in the MkvMerge M4A demuxer.

... you can use other encoders (if you have the required soft not included in eac3to) to output AAC with standard ADTS headers. For instance:

eac3to input | qaac -V 99 --ignorelength --adts --no-delay -o output.aac -
That might be a good alternative. What is the quality of the QAAC encoder? Is it comparable to the Nero encoder?

EDIT:
When Mkvmerge mux a m4a from NeroAacEnc always correct the delay cutting the first frames and add a -9ms of delay to track.
If AAC is extracted and after remuxed the delay -9ms dissapear.
For me that is the only difference between mkv's, maybe your player have problems with the delay. Well, the sound plays in sync with the video, so I guess it's not a delay problem. I don't understand why that -9 ms delay is necessary, but obviously it's also a problem related to the M4A container.

r0lZ

27th September 2015, 08:52

Don't forget stdout.wav after input.Thanks for the precision.

I already had the same kind of problem with videos : when I open a TS including interlaced H264 in MKVmerge, it creates a file considered as VFR by MediaInfo (while it's CFR).
But if I demux the video with TSMuxer then open the ES in MKVmerge, the video is correctly considered as CFR by MediaInfo (as the original TS, there is no error in the TS stream).

It seems MKVmerge has problems with some containers or headers.I mux a h264 elementary stream (encoded with x264) and a SRT stream with the M4A or AAC stream. IMO, it's something that MkvMerge should handle without problem. And anyway, if it's a problem with the video, that doesn't explain why the audio container causes the problem.

tebasuna51

27th September 2015, 09:41

Don't forget stdout.wav after input.
My fault, I forget the stdout.wav. Corrected in the post.

Do you mean that the encoding type changes when the quality is less than 0.35?
Yep, in all my test using 0.34 or less the output is HE, using 0.35 or higer the output is LC.

Anyway, the advantage of the M4A container is that it has the correct info, and it should not be necessary to specify the HE flag to MkvMerge. BTW, I did my test with the default quality 0.5.
Then your problem can't be about that.

That might be a good alternative. What is the quality of the QAAC encoder? Is it comparable to the Nero encoder?
Of course, QAAC is, for now, considered the best AAC encoder at low bitrates, for high bitrates we can't make test because the output can't be differentiated.

I don't understand why that -9 ms delay is necessary, but obviously it's also a problem related to the M4A container.
I'm not sure is this can cause the problem and how MkvMerge mux the m4a.

I will make some test about that.

tebasuna51

27th September 2015, 09:49

It is the log file:
eac3to v3.29
d:\eac\eac3to.exe" "E:\my video\movie.mkv" 2: "E:\my video\movie2eng.ac3"
...
2: TrueHD (Atmos), English, 7.1 channels, 48kHz
...

It is the first time I can not extract AC3.

In a mkv the THD can't have a embedded AC3, that is only possible in m2ts (bluray) container. Then the AC3 can't be extracted, only recoded.
Check if the mkv have the AC3 in other track.

LeXXuz

27th September 2015, 11:48

eac3to writes MKV files through the Haali MKV Muxer DirectShow filter. However, all other files are created and written to directly by eac3to. Replacing the Haali MKV Muxer would be quite a lot of work, so don't expect that anytime soon.

It's been 2 years. Any news on this issue? Any plans to ditch the old mkv muxer for ffmpeg or others?

r0lZ

28th September 2015, 04:49

Of course, QAAC is, for now, considered the best AAC encoder at low bitrates, for high bitrates we can't make test because the output can't be differentiated.If it is so good, why is it not distributed with eac3to? Rights problem?

I will make some test about that.Don't waste your time. I can do the tests myself and anyway I think I'll use QAAC (at least if I can freely distribute it with BD3D2MK3D).

Thanks for your help.

tebasuna51

28th September 2015, 10:08

If it is so good, why is it not distributed with eac3to? Rights problem?

Yep, the dll's needed can be obtained freely (see makeportable.zip in https://sites.google.com/site/qaacpage/cabinet ) but not distributed.

Thunderbolt8

28th September 2015, 10:52

would it then be possible to add a download dialogue in which the user is asked if eac3to should download the files now?

LigH

28th September 2015, 18:35

Adding a download routine like wget may be beyond the purpose of a CLI audio converter; it could at most call a ShellExecute of the URL to spawn a browser, IMHO.

But the QAAC download URL could certainly be readable in the documentation (maybe added to "\legal stuff\qaac" then, with a brief guide how to use the CoreAudioToolbox without actually installing QuickTime or even iTunes).

I believe many authors prefer a link to a download site over a direct download link; the latter may change sometimes, already depending on the version (well, eac3to is a partial exception here, always having the latest version at the same URL).

r0lZ

29th September 2015, 10:03

Yep, the dll's needed can be obtained freely (see makeportable.zip in https://sites.google.com/site/qaacpage/cabinet ) but not distributed.Damn! When I have seen that QAAC requires the libraries from the iTune package, I was about to abandon the idea to support it in BD3D2MK3D. I can't force the users to install that junk just to be able to convert to AAC. I will see what I can do with the makeportable archive. If it's easy enough, I'll add an option to use either Nero or QAAC and if QAAC is not already installed when the user selects it, I'll display a dialog with the link and instructions to download and install the required archives.
Thanks to everybody here!

tebasuna51

29th September 2015, 12:49

... I'll display a dialog with the link and instructions to download and install the required archives.
1) You can distribute qaac.exe (now v2.55) and makeportable.cmd in ...\BD3D2MK3D\toolset subfolder (like eac3to), notes:

- There are a 64 bit versión but you can use the 86 version to avoid problems.
- The files libsoxconvolver.dll, libsoxr.dll and refalac.exe are not needed to AAC conversión, only to advanced parameters not used automatically or ALAC conversión.

2) Then you need download iTunes6464Setup.exe (now iTunes 12.3) in the same subfolder. There are the required dll's for 32 and 64 bits.

3) Run makeportable.cmd than create QTfiles and QTfiles64 subfolders.
EDIT: To run makeportable.cmd you need 7z (http://www.7-zip.org/) decompressor installed in your sytem.

4) You can delete iTunes6464Setup.exe, and the QTfiles64 folder if don't want use the 64 bits version. And you have qaac ready to work with eac3to:

"[path]eac3to" "input" stdout.wav | "[path]qaac" -V 99 --ignorelength --adts --no-delay -o "[path]output.aac" -

About qaac quality you can see:
HydrogenAudio test
-----------------------
V 0 - V 4 = ~ 40 kb/s
V 5 - V 13 = ~ 45 kb/s
V 14 - V 22 = ~ 75 kb/s
V 23 - V 31 = ~ 80 kb/s
V 32 - V 40 = ~ 95 kb/s
V 41 - V 49 = ~105 kb/s
V 50 - V 58 = ~115 kb/s
V 59 - V 68 = ~135 kb/s
V 69 - V 77 = ~150 kb/s
V 78 - V 86 = ~165 kb/s
V 87 - V 95 = ~195 kb/s
V 96 - V104 = ~225 kb/s
V105 - V113 = ~255 kb/s
V114 - V122 = ~285 kb/s
V123 - V127 = ~320 kb/s
The V values have ranges, is the same put V 96 than V104.
The test was made with stereo music sources, with audio movies tracks the bitrate can be less than that.

I my test V 99 is, more or less, equivalent to Nero q 0.5, V 90 -> q 0.46, V 82 -> q 0.42

----------------------
A workaround to extract the aac from Nero .m4a can be:

MP4Box -out adts.aac -raw 1 nero.m4a

But the aac need a -55ms delay, like a aac (48 KHz) frame duration is 21.333 ms you can cut the first 3 frames with:

eac3to adts.aac adtsDelayed.aac -64ms

And now need a +9ms delay. This is the procedure than use MkvMerge when mux the .m4a.
You can forget the +9ms delay because can't be distinguished (less than a video frame duration)

Thunderbolt8

29th September 2015, 20:04

it would at least be nice to give the user a note when trying to get some .aac output that for best .aac quality he needs to install some additional stuff. so that way the user knows there is still room for improvement. I guess most people have the assumption that the best possible way to deal with .aac is already that which is eac3to doing/that which already comes with eac3to.

r0lZ

30th September 2015, 07:58

Thanks for the additional precisions, tebasuna51. I think I'll implement that (perhaps with a step by step wizard to help the user install the required stuff without problem).

@Thunderbolt8: I agree.
I was convinced that Nero was the best AAC encoder (at least among the free solutions). IMO, by default eac3to should always use the free solution that it can distribute, but it should also show in his help screen the best commercial or not freely distributable solution, perhaps with short instructions on how to obtain, install and use them or with a link to an online help page with complete instructions. This thread here is way too long and complicated to constitute a valuable help for the complete installation of eac3to.

LigH

30th September 2015, 08:21

NeroAacEnc is still one of the better AAC encoders, certainly convenient for most cases; but fdkaac and Apple CoreAudioToolbox surpassed it already in "best of" listening tests. Differences are marginal. They all can compete with Vorbis and surpass LAME, no reason to mourn.

A major disadvantage of fdkaac is the width of gaps between bitrate target presets. Tuning is better with qaac and free with Nero.

tebasuna51

30th September 2015, 11:54

I forget a requirement to decompress iTunes6464Setup.exe with makeportable.cmd. You need 7z installed (always recommended) in your system (added to post).
----------------

Like I say before the NeroAacEnc quality (with q >= 0.4) is equivalent to other encoders.
The question here is the problem detected by r0lZ when mux m4a with MkvMerge.

Anybody experiment the same problem (choppy sound with mono or 5.1 from .m4a)?

Is a MkvMerge problem (seems solved using .aac)?

sneaker_ger

30th September 2015, 15:52

When I use eac3to to convert an audio track to AAC, it produces the AAC track within a M4A container. That M4A file can be muxed directly with the video track with MkvMerge. But often, the sound is choppy when I play the resulting MKV on my Samsung TV. (The same file can be played without problem with all software players I have tried so far.)

If I extract the AAC track from the M4A and then mux it with MkvMerge, there is no problem any more. The sound is perfect, including when it is played with my TV.
Only "often", not always? Is it reproducible or erratic even with the same file?
Can you test these samples:
https://www.sendspace.com/file/lcnqy5

Motenai Yoda

1st October 2015, 01:24

I forget a requirement to decompress iTunes6464Setup.exe with makeportable.cmd. You need 7z installed (always recommended) in your system (added to post).

Why not the portable version?

LigH

1st October 2015, 08:53

IMHO, it should be possible to ship the static CLI version with other projects, if I'm not wrong. Was it the 7za.exe in the extras archive? May have to read the docs texts again...

tebasuna51

1st October 2015, 10:19

IMHO, it should be possible to ship the static CLI version with other projects, if I'm not wrong. Was it the 7za.exe in the extras archive?...
Seems than 7za.exe can extract AppleApplicationSupport*.msi from iTunes6464Setup.exe but not QTfiles* from AppleApplicationSupport*.msi.

Tested stable v9.20 and last beta v15.07, maybe because:
7za.exe - standalone console version of 7-Zip with reduced formats support.

EDIT: In my system (7z installed but not in PATH) work with only 7z.exe and 7z.dll (from 7z920.exe) in the same folder.
But I can't guarantee than work in all system's.

r0lZ

1st October 2015, 11:48

Only "often", not always? Is it reproducible or erratic even with the same file?
The problem occurs systematically when I mux the same video and audio files. When I've noticed the problem (with the mono WAV and 5.1 DTS streams), there is a gap in the sound every 2 seconds or so, regardless of the state of the HE flag in MkvMerge. (I know that it should be ignored when the input file is a M4A, but I've tried anyway with the flag in automatic, on and off modes, just to be sure).

I have then made another test, with a short clip (faster to mux) and another M4A, and the problem was still present, but much less evident. There was a gap only every 15 seconds or so, and it was less audible. But again, when muxing the AAC extracted from the M4A, there was no problem at all.

Therefore, it seems that the problem can be reproduced, but with different results. I have written "often" because usually I'm not interested in converting the original DTS or AC3 audio to AAC, and therefore I have not often the occasion to test that problem with my TV. But I'm sure I have already played movies with AAC audio without the problem. Maybe the AAC stream have been muxed directly, or another version of MkvMerge has been used. Or perhaps it's also related to the video? I don't know. I can't be sure that the problem occurs always, but since I've discovered it, I can confirm that it occurs systematically.
Strangely, the choppy sound problem occurs only when I play the movie with my Samsung TV. I suppose that it's a combination of 2 little bugs (one in the M4A when it is created by eac3to or when it is muxed by MkvMerge, and one in my TV).
Can you test these samples:
https://www.sendspace.com/file/lcnqy5
I'll do it when I'll have some time.
I will also try to mux it with different video streams.

kypec

1st October 2015, 12:18

Strangely, the choppy sound problem occurs only when I play the movie with my Samsung TV. I suppose that it's a combination of 2 little bugs (one in the M4A when it is created by eac3to or when it is muxed by MkvMerge, and one in my TV).
:thanks:
I noticed the audio choppiness in one of my remuxes as well. I'm using serviio (http://serviio.org) media streamer from my Windows 7 desktop PC to Samsung TV (model UE40D6000) over cabled LAN (not wi-fi). I assumed that choppiness was due to extremely high bitrate of video+audio stream since it's a straight remux of Disney's Frozen BD but maybe it was indeed due to some strange bug that involves specific MkvMerge / M4A audio file / TV firmware / whatever. I'll recheck when I'll find some spare time...

Music Fan

1st October 2015, 20:59

I have a problem with eac3to that often happens, I had never thought to mention it here ; with TS recordings (done with my STB), eac3to only detects video but not sound. And there are apparently no differences between files whose sound is detected and others.

Xorp

2nd October 2015, 01:34

The latest eac3to build now automatically switches to dcadec for all DTS 7.x tracks. However, because the new decoder isn't that well tested yet, for all other channel configurations ArcSoft is currently still the default decoder option (if it's available, otherwise dcadec becomes default).

So it's been more than 6 months since this post. Has anyone discovered any really bad bugs with -dcadec? Should I force it's use with all DTS now?

Sparktank

2nd October 2015, 04:53

So it's been more than 6 months since this post. Has anyone discovered any really bad bugs with -dcadec? Should I force it's use with all DTS now?

Still issues with DTS Express formats.
https://github.com/foo86/dcadec

Features not implemented:

Decoding of DTS Express streams
Applying dynamic range compression and dialog normalization

r0lZ

2nd October 2015, 09:04

:thanks:
I noticed the audio choppiness in one of my remuxes as well. I'm using serviio (http://serviio.org) media streamer from my Windows 7 desktop PC to Samsung TV (model UE40D6000) over cabled LAN (not wi-fi). I assumed that choppiness was due to extremely high bitrate of video+audio stream since it's a straight remux of Disney's Frozen BD but maybe it was indeed due to some strange bug that involves specific MkvMerge / M4A audio file / TV firmware / whatever. I'll recheck when I'll find some spare time...
My Samsung TV is an UE40D6500, but I play most movies directly with the TV (HDD connected via USB, not streaming).
I will try with a straight remux to see if I have the same problem. Can you describe exactly what you did to obtain the "straight remux"? Demuxing with eac3to or tsMuxeR? What streams have you kept? All audio streams? And the AVC video has not been re-encoded, right?

r0lZ

2nd October 2015, 09:08

Has anyone discovered any really bad bugs with -dcadec?It is now used by default by BD3D2MK3D, and nobody has reported problems. But since BD3D2MK3D processes only 3D movies and DTS-Express is not allowed as primary audio, BD3D2MK3D should never need to convert DTS-Express tracks. IMO, eac3to should use DCADEC by default for all DTS tracks except DTS-Express.

tebasuna51

2nd October 2015, 09:13

Like Sparktank, and r0lZ, say dcadec work fine (even better than ArcSoft) for all DTS except DTS Express.

"Applying dynamic range compression and dialog normalization" is a not desired feature, eac3to always try not apply dynamic range compression and dialog normalization to decode sources.

Xorp

2nd October 2015, 17:08

It is now used by default by BD3D2MK3D, and nobody has reported problems. But since BD3D2MK3D processes only 3D movies and DTS-Express is not allowed as primary audio, BD3D2MK3D should never need to convert DTS-Express tracks. IMO, eac3to should use DCADEC by default for all DTS tracks except DTS-Express.

Thanks for the info guys. I can't ever see myself needing DTS-Express decoding since they are usually for the PiP audio, so sounds like dcadec is the winner.

gabbett1

2nd October 2015, 20:38

So I've been trying to convert my Bluray Insurgent to an MP4 and the old version of Ripbot I had been using wouldn't find any audio tracks other than 2.0 versions. I decided to upgrade to this newest version, also updating all the components needed (AviSynth , Haali Media Spliter , ffdshow). I'm running windows 7 btw. So anyhow, now I can't demux my streams. I keep getting a demuxing error:

eac3to v3.29
command line: "J:\Blue Ray Ripping\Tools\eac3to\eac3to.exe" "J:\Rip\INSURGENT\" 1) 2: "J:\Temp\RipBot264temp\job1\video.mkv" -seekToIFrames 3: "J:\Temp\RipBot264temp\job1\audio_1_English.thd.w64" -down16 -down6 8: "J:\Temp\RipBot264temp\job1\8_subtitles_English_1080.sup" 9: "J:\Temp\RipBot264temp\job1\9_subtitles_English_1080.sup" 10: "J:\Temp\RipBot264temp\job1\10_subtitles_Spanish_1080.sup" 1: "J:\Temp\RipBot264temp\job1\chapters.txt" -progressnumbers -log="J:\Temp\RipBot264temp\job1\demuxlog.txt"
------------------------------------------------------------------------------
M2TS, 1 video track, 5 audio tracks, 3 subtitle tracks, 2:00:00, 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 Surround, English, 2.0 channels, 224kbps, 48kHz
5: AC3 Surround, English, 2.0 channels, 224kbps, 48kHz
6: AC3, Spanish, 5.1 channels, 640kbps, 48kHz
7: AC3 Surround, English, 2.0 channels, 224kbps, 48kHz
8: Subtitle (PGS), English
9: Subtitle (PGS), English
10: Subtitle (PGS), Spanish
[a03] thd, 48000, 7.1
Creating file "J:\Temp\RipBot264temp\job1\chapters.txt"...
[s10] Extracting subtitle track number 10...
[a03] Extracting audio track number 3...
[s08] Extracting subtitle track number 8...
[s09] Extracting subtitle track number 9...
[v02] Extracting video track number 2...
[a03] Decoding with libav/ffmpeg...
[a03] Mixing surround channels...
[a03] Reducing depth from 24 to 16 bits...
[a03] Writing W64...
[a03] The libav decoder reported error -1094995529 while decoding. <ERROR>
Aborted at file position 1048576. <ERROR>

I need help resolving this issue.

73ChargerFan

2nd October 2015, 21:53

Thunderbolt8

3rd October 2015, 12:02

in case of such multiple potentially correct playlists it has always been the case that the correct one does not necessarily have to be 1)

gabbett1

3rd October 2015, 13:35

I think the Insurgent BD is engineered to break eac3to. It appears to use playlist spoofing, so that the playlist which eac3to identifies as the main movie playlist " 1) " is likely incorrect.

To confirm, run:
"J:\Blue Ray Ripping\Tools\eac3to\eac3to.exe" "J:\Rip\INSURGENT\"

and it will tell you which playlist "xxxxx.mpls" it associates with 1)

Next play that playlist using mpc-hc or mpc-be to determine if it is valid or garbage.

Hmm, well originally I used Process Monitor to find the correct playlist. It just happened to be #1 on the list. Maybe I'll have to try it again to make sure I found the correct mpls the first time.

As far as this goes:
To confirm, run:
"J:\Blue Ray Ripping\Tools\eac3to\eac3to.exe" "J:\Rip\INSURGENT\"

When I look in that folder the only things inside are:
yr_eac3to_more_gui.exe
yr_eac3to_more_gui.ini

gabbett1

3rd October 2015, 13:56

Ran the Process Monitor again and realized I made a mistake. 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) 2: "J:\Temp\RipBot264temp\job2\video.mkv" -seekToIFrames 3: "J:\Temp\RipBot264temp\job2\audio_1_English.thd.w64" -down16 8: "J:\Temp\RipBot264temp\job2\8_subtitles_English_1080.sup" 9: "J:\Temp\RipBot264temp\job2\9_subtitles_English_1080.sup" 10: "J:\Temp\RipBot264temp\job2\10_subtitles_Spanish_1080.sup" 1: "J:\Temp\RipBot264temp\job2\chapters.txt" -progressnumbers -log="J:\Temp\RipBot264temp\job2\demuxlog.txt"
------------------------------------------------------------------------------
M2TS, 1 video track, 5 audio tracks, 3 subtitle tracks, 1:59:00, 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 Surround, English, 2.0 channels, 224kbps, 48kHz
5: AC3 Surround, English, 2.0 channels, 224kbps, 48kHz
6: AC3, Spanish, 5.1 channels, 640kbps, 48kHz
7: AC3 Surround, English, 2.0 channels, 224kbps, 48kHz
8: Subtitle (PGS), English
9: Subtitle (PGS), English
10: Subtitle (PGS), Spanish
[a03] thd, 48000, 7.1
Creating file "J:\Temp\RipBot264temp\job2\chapters.txt"...
[s10] Extracting subtitle track number 10...
[s08] Extracting subtitle track number 8...
[s09] Extracting subtitle track number 9...
[v02] Extracting video track number 2...
[a03] Extracting audio track number 3...
[a03] Decoding with libav/ffmpeg...
[a03] Reducing depth from 24 to 16 bits...
[a03] Writing W64...
[a03] The libav decoder reported error -1094995529 while decoding. <ERROR>
Aborted at file position 1048576. <ERROR>

Thunderbolt8

3rd October 2015, 23:35

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

ScottJ

3rd October 2015, 23:47

[a03] The libav decoder reported error -1094995529 while decoding. <ERROR>
Aborted at file position 1048576. <ERROR>

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

r0lZ

4th October 2015, 08:42

Have you tried to demux with tsMuxeR?

jpsdr

4th October 2015, 09:05

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

If i remember properly, when "recently" madshi update eac3to to fix some little issues and add the new dts decoder, he didn't update the ffmpeg part of eac3to, which begin to be a little old. So there is a big chance that this statement is indeed the right answer.

Boulder

4th October 2015, 10:11

eac3to should handle Atmos just fine, that is why madshi released a new version some time ago. He just added the Atmos code to his build to save time.

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?

nevcairiel

11th October 2015, 16:28

Extra 0 bits don't hurt the audio at all, so you could just leave it as is. Or since the only part that has 24-bit data is apparently "junk", just let eac3to process it in 24-bit and reduce to 16 afterwards if you want to save space.

ndjamena

11th October 2015, 16:34

Doh!

The problem is that it's converting the 16 bit segments to 24 bit (at least if I process each m2ts file separately eac3to reports all but the first as being constant 16 bit, yet if I extract the whole movie with eac3to my program reports 24 bit segments in the resulting WAV file), it just occurred to me that maybe -dontdither will stop that. If I use -dontdither AND -down16 maybe...

Assuming it doesn't try to upsample the 16 bit first that should work. No?

ndjamena

11th October 2015, 17:57

Nope, -dontdither -down16 didn't work. Neither did -dontdither -down16 -dontPatchDts.

Leaving out the first file accomplishes nothing.

I'm out of options.

As far as I can tell there is no way of ripping mixed "16 bit in 24 bit" and "16 bit in 16 bit" tracks from a blu ray neatly as 16 bit using any program I can think of, much less with the addition of the junk in the first file.

Sparktank

12th October 2015, 02:30

Then use just "-down16".
The final file for the whole stream will be 16bit.

If you want to keep it all, use FLAC. If you can't use FLAC, then take it with a grain of salt and convert all to 16-bit.

ndjamena

12th October 2015, 02:58

If I use -down16 the STATED bit depth of the whole stream will be 16 bit, but the actual bit depth for the majority of the stream will be 10-bit...

Won't it?

(I have no idea what Eac3to is doing.)

Sparktank

12th October 2015, 03:34

It... shouldn't.

It just means the whole stream will be dithered down to 16 bits, even the single, small, tiniest part that's actually 24-bit.
Anything that's actually 16bit will have nothing happen to it.

eac3to wouldn't dither below 16bit for anything.

The "stated" bit depth is 24 if you use the whole stream.
Using each segment (m2ts), the stated bit depth for each is what you observe: 16 or 24.

ndjamena

12th October 2015, 04:35

Well, obviously I have no idea how audio works.

The wav files are little endian and as far as I can tell it is the most significant bits that are missing (the first byte of three).

The first byte of each group of 3 (24 bits) is zero, if the "endian" is "little" then that would make the first byte the "big" one... and that's what's missing...

Are the samples stored backwards for some reason?

Is it actually the LEAST significant bits that are missing?

That would solve everything.

-edit- oh, so either most significant doesn't mean biggest it means first, or "end" means "start"... or something...

From wikipedia:

For example, the number 123, has the hundreds-digit, 1, left-most which is understood by a numerate reader. This is an example of a big-endian convention taken from daily life.

-so little endian would store the byte that contains the smaller value first and downsampling would pretty much just remove that byte.

-edit2- Little Endian = LITTLE END FIRST

nevcairiel

12th October 2015, 08:25

The endianess makes no difference at all. Its just something for eac3to to handle, not for you to ever think about.

ndjamena

12th October 2015, 09:19

I was looking at the WAV file with a hex editor to see what was going on.

Basically:

16 bit audio: 12
24 bit audio: 123
16 bit in 24 bit: 120
24 bit converted to 16 bit: 12
16 bit in 24 bit converted to 16 bit: 12

In case anyone else was confused as to how 16 bit in 24 bit audio was configured. The extra zeros are added to the small end of the sample, not the big end, effectively multiplying the value by 256. It's the equivalent of adding an extra zero to 12 to make 120 and alters the magnitude of the scale while keeping the same difference between the original sample points. 12 to 11 is the same as 120 to 110 but altering the zero gives you room to add precision which would give you the equivalent of true 24 bit audio.

That's why the volume stays the same between simply stripping the zeros and doing a proper resampling.

Stripping zeros is still better than resampling since resampling isn't lossless (with an even number of outcomes there's no middle point in whole byte numbers, it SHOULD be zero but then there will always be one more negative number than positive, so they simply don't scale well, silence (0s) winds up getting speckled with random noise(-1s)).

At least one person reading this thread didn't know that, and no one seemed willing to point it out.

tebasuna51

12th October 2015, 11:48

@ndjamena
I read your discussion without understand what you want do.

1) Save space downsampling DTS-MA 24 to 16 bits in m2ts's?

a) If the main movie is a real 24 bits you lose precission, not volume.
b) If is real 16 bits and only credits have real 24 bits you can save only a few space.
c) If is a fake 24 bits (16 bits + 8 0's) you can save space without lose precission or volume.
d) If is 20 bits you lose less precission downsampling to 16 bits, but 20 bits is not a standard format and can't be used.

2) Save space when recode to a lossless format like FLAC?

Then in cases b) or c) is recommended, and safe, use -down16
In cases a) or c) you lose precission using -down16

3) About endianess.
You must trust in proper soft, like eac3to, than manage endianess without problems.
Only the less significant byte is deleted with -down16 and the volume remain the same.

When output .WAV and .W64 are always little endian samples.
And when output .PCM are always big endian samples. (not recommended use this format because is without header)
EDIT: Also when output multichannel .PCM the channel order is not the same than WAV or W64

ndjamena

12th October 2015, 12:19

I ran out of hard drive space and discovered what a PITA trying to watch from the disc was, so I'm re-ripping, removing all the extra audio tracks and down sampling the main lossless tracks to 16 bit FLAC until I can afford a rack mount.

I saved 20GB just converting the audio to 16 bit FLAC on the X-Men movies alone so I figure I'm on the right track here.

(My WDTV SMP won't play 24 bit FLAC from an MKV without glitching, I had been converting to full bitdepth FLAC AND keeping the original track as well, plus all the commentary/audio description tracks and whatnot... so there's plenty of reasons to go down this track for now.)

I didn't know how 16 bits in 24 bits worked, from the simple way it's described I assumed it just used smaller numbers that would easily fit in a 16 bit integer, apparently Dark Space thought the same thing. But the numbers are the same size, it's just that the less significant 8 bits are empty, which is where the extra precision between 24 and 16 bit comes from, which leaves them pretty much exactly the same as 16 bit audio when those 8 bits are removed.

Should I have known that from the getgo?

ndjamena

12th October 2015, 18:09

When I used -down16 -dontdither on Terminator Salvation it destroyed the audio in the true 16 bit segments.

I'm thinking that's a bug, although I don't suppose I'm supposed to be using the -dontdither switch at all.

What would it have done? If it dithered the 16 bit up to 24 bit and then didn't dither it back to 16 bit it still should have turned out fine... no?

Would it have added zeros to the big end of the 16 bit section when up sampling and then taken the little end away when down sampling?

I should probably test it but I've deleted the blu ray structure and would have to rip it again.

-Edit- When using -down16 on silent PCM without -dontdither at least a sixth of the zeros are changed into either 1s or negative 1s.

gabbett1

13th October 2015, 22:32

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.

I'm confused. The link just puts me to reply to this forum.

LigH

13th October 2015, 23:07

^ I guess he caught a wrong URL in his clipboard; Ctrl+C is sometimes unreliable. It's probably this post (http://forum.doom9.org/showthread.php?p=1742199#post1742199) (plus some previous and following). Apparently Transport Streams are not as trivial and unambiguous as one may expect.

Thunderbolt8

14th October 2015, 16:41

yes, sorry. wrong ctrl+c

ndjamena

20th October 2015, 13:25

OK, so when appending an m2ts file with 16 bit DTS-MA to an m2ts file with 24 bit DTS-MA using eac3to even without using any switches, the 16 bit segment will be reduced to silence. All the higher order bits will be set to either FFF or 000 and the rest is pretty much nothing but noise. Extracting the 16 bit segment by itself produces perfect output. The fact that it doesn't issue an error or even a warning seems to indicate that that's actually a bug.

And when down sampling to 16 bit eac3to DOESN'T try to squeeze the number from a scale of 16777215 to a scale of 65535, it just removes the lower eight bits, then applies "dithering" which is basically just random noise to hide the artificial "colouring" of the sound any down sampling method must create. It applies the dithering even if what it's processing is nothing but perfect silence. The -dontdither switch supresses the application of any dithering.

LigH

20th October 2015, 13:42

A good dither algorithm is not necessarily random, it may even be better. If the original values with higher precision are known, then they can be used to calculate lower precision values with a medium "virtual precision" by distributing the error across neighbor values, so that the weighted average of neighbor samples approaches the former more precise value better. From image processing you may know ordered dither patterns (Bayer) or error propagation noise (Floyd-Steinberg etc.); audio dithering can work in a similar way. Properly implemented (in relation to "noise shaping"), it can do miracles in low volume scenes. I do not know, though, how eac3to works in this regard...

nevcairiel

20th October 2015, 15:55

And when down sampling to 16 bit eac3to DOESN'T try to squeeze the number from a scale of 16777215 to a scale of 65535, it just removes the lower eight bits, then applies "dithering" which is basically just random noise to hide the artificial "colouring" of the sound any down sampling method must create It applies the dithering even if what it's processing is nothing but perfect silence. The -dontdither switch supresses the application of any dithering.

That is the correct way to do this. Anything else would not result in the expected audio. And you should never disable dithering.

A good dither algorithm is not necessarily random, it may even be better.

Audio Dithering is generally always based on randomness, so you can guarantee no unwanted harmonic interference piles up somewhere.
Even "Noise Shaping" uses randomness at its base, its just transformed slightly to move the random noise into desired frequency regions.

Motenai Yoda

28th October 2015, 09:11

And when down sampling to 16 bit eac3to DOESN'T try to squeeze the number from a scale of 16777215 to a scale of 65535, it just removes the lower eight bits

It's the same thing, divide by 256 then truncate (if you don't work in int), give you bit identical result than just a 8bit shift to right.

Thunderbolt8

30th October 2015, 15:28

is the dcadec decoder able to decode DTS:X streams?

Smithy

30th October 2015, 16:12

2015 DTS Blu-Ray Demo Disc Vol.19

Decode Divergent DTS:X without errors.

MKV, 1 video track, 1 audio track, 0:02:01, 24p /1.001
1: h264/AVC, English, 1080p24 /1.001 (16:9)
2: DTS Master Audio, English, 7.1 channels, 24 bits, 48kHz
(core: DTS, 5.1 channels, 1509kbps, 48kHz)
[a02] dts, 48000, 7.1
[a02] Extracting audio track number 2...
[a02] Decoding with libDcaDec DTS Decoder...
[a02] Writing WAV...
[a02] Creating file "V:\DTSX Demo - Divergent.wav"...
[a02] The original audio track has a constant bit depth of 24 bits.
Video track 1 contains 2904 frames.
eac3to processing took 14 seconds.
Done.

Thunderbolt8

30th October 2015, 18:09

but can we be sure that everything in it has been decoded and used correctly? how does DTS:X work, is it some extension like atmos for TrueHD? maybe then just the "core" DTS-HD MA track was used and not the DTS:X extension?

Smithy

30th October 2015, 18:37

sound is fine.
the core is 5.1 not 7.1 ;)

Thunderbolt8

30th October 2015, 18:41

sound is fine.
the core is 5.1 not 7.1 ;)I dont mean the DTS core inside the DTS-HD MA track, but something like possibly a DTS-HD MA core inside the DTS:X track. or a DTS:X extension which could be stripped or dropped and perhaps we wouldnt know of it.

Thunderbolt8

30th October 2015, 18:44

sound is fine.
the core is 5.1 not 7.1 ;)I mean not the DTS core inside the DTS-HD MA track, but something like possibly DTS-HD MA core inside the DTS:X track. or DTS:X extension which could be stripped or dropped and perhaps we wouldnt know. so eac3to could either recognize only this known "DTS-HD MA" core inside the full DTS:X track or not recognize the DTS:X extension of the full track (in case it works like an extension) and therefore disregards the part it doesnt know.

dcadec was last modified 5 months ago on github, not sure how many DTS:X test samples have already been available back then to help with the implementation.

Smithy

30th October 2015, 18:50

yes, this part is doesn't know

but dts-hd ma is the core Track of DTS:X for backward Compatibility like THD (Atmos) or PCM (Auro3D)

and DTS:X is more Special vs. THD ATMOS, maybe its possible to decode DTS:X

gabbett1

1st November 2015, 15:44

madshi

1st November 2015, 16:21

eac3to v3.30 released

http://madshi.net/eac3to.zip

* libDcaDec is now default for all DTS tracks except XSA / low bitrate
* fixed: #310: Use ffmpeg like external encoder
* fixed: #312: Convert to wav with a big negative delay works incorrectly
* fixed: #314: 'edit' option adds one frame less than expected
* fixed: #345: Fails to decode Atmos track with no embedded AC3 track

SeeMoreDigital

1st November 2015, 16:30

Thanks madshi :)

ron spencer

1st November 2015, 20:10

fixed #345 is sweet!!

for:

libDcaDec is now default for all DTS tracks except XSA / low bitrate

Does this mean the Arcsoft decoder is not longer needed?

tebasuna51

1st November 2015, 22:34

Thanks madshi!

Does this mean the Arcsoft decoder is not longer needed?

Only for DTS-Express:

* libDcaDec is now default for all DTS tracks except XSA / low bitrate

Sparktank

2nd November 2015, 05:45

Good news, everybody!

Thanks for the update. :)

r0lZ

2nd November 2015, 10:03

Thanks for the update, but I'm just too late to report that libDcaDec may have a bug. It fails to decode some DTS HD MA tracks extracted from BDs, with the message "Synchronisation error". However, as far as I can tell, there is no sync error, the track seems perfect, I can't hear any glitch, the DTS core can be extracted without problem and the other decoders (Libav and Arcsoft) work fine. I have had that problem already 3 times, so it seems that it's not a minor problem. I have a DTSHDMA track causing the problem but unfortunately it is way too big (2.7 GB) to be uploaded somewhere, and the sync error happen near the end. Can I simply cut it at any position and upload the end of the file? I guess that will not work. Right?

Also, madshi, please reopen this bug: Failure to demux subtitle tracks from SSIF or MPLS of a 3D-BD (http://bugs.madshi.net/view.php?id=87)
I have never received the notifications for the message with your request for a sample. I can't provide a sample if I don't know that it is needed.

Boulder

2nd November 2015, 10:16

You might want to report the libdcadec problem here: https://github.com/foo86/dcadec/issues . I see no reason why the sync error wouldn't occur after cutting the file.

madshi

2nd November 2015, 10:30

Thanks for the update, but I'm just too late to report that libDcaDec may have a bug. It fails to decode some DTS HD MA tracks extracted from BDs, with the message "Synchronisation error". However, as far as I can tell, there is no sync error, the track seems perfect, I can't hear any glitch, the DTS core can be extracted without problem and the other decoders (Libav and Arcsoft) work fine. I have had that problem already 3 times, so it seems that it's not a minor problem. I have a DTSHDMA track causing the problem but unfortunately it is way too big (2.7 GB) to be uploaded somewhere, and the sync error happen near the end. Can I simply cut it at any position and upload the end of the file? I guess that will not work. Right?
You can use a negative delay value in eac3to to remove the start of the track. Samples are important for problems like this. But I can't personally fix them, so you need to report such bugs to the dcaDec developer:

https://github.com/foo86/dcadec

Also, madshi, please reopen this bug: Failure to demux subtitle tracks from SSIF or MPLS of a 3D-BD (http://bugs.madshi.net/view.php?id=87)
I have never received the notifications for the message with your request for a sample. I can't provide a sample if I don't know that it is needed.
You can reopen the bug yourself, you don't need me to do that. I've already given all users the right to reopen bugs.

r0lZ

2nd November 2015, 15:25

OK, thanks.

I have already reported the problem on the dcadec bug tracker here (https://github.com/foo86/dcadec/issues/38#issuecomment-153026239), with this sample (http://download.videohelp.com/r0lZ/tmp/DTS_HD_MAsync_bug_sample.dts), and they have replied this:

FWIW, the libdcadec wrapper in FFmpeg does not encounter any error - which indicates that the dcadec decoder is working fine, and the problem may be in reading/parsing the file.

So, it seems that the error is not related to the dcadec decoder, and may be caused by eac3to or something else. Any thoughts?

I will re-open the demux SSIF bug, but I have to create a sample first...

r0lZ

2nd November 2015, 16:39

Madshi, I have seen your reply in the dcadec bug tracker. Thanks.

To facilitate the decoding (at least while the origin of the "bug" is unclear), is it possible to turn off the DCADEC_FLAG_STRICT via eac3to's command line ? How ? Or is it only a flag that can be changed at compile time ?

If it's not possible, can you consider turning it off in a forthcoming version?

madshi

2nd November 2015, 16:53

Please add an issue to the bug tracker to request an option to turn the strict decoding mode off, so that I don't forget it. It can currently only be changed in eac3to by recompiling.

tebasuna51

2nd November 2015, 17:40

I don't know if that's help:

Decoding the sample with a recent ffmpeg, finish without errors, but using ffmpeg version N-71329-g235589e 07-Apr-2015 finish with:

libdcadec/exss_parser.c+395: Invalid EXSS size0kbits/s

The output for both versions are bit-identical.

Maybe you can output a <WARNING> but continue the decode.

madshi

2nd November 2015, 17:47

Boulder

2nd November 2015, 17:54

I propose a parameter to disregard the error, just because dcadec is the only freeware solution to decoding such files :)

AYColumbia

3rd November 2015, 00:42

Thanks for the update madshi.

jpsdr

3rd November 2015, 09:52

Thanks for the update madshi.
And, it's just to know what the actual statut is, do you also have update ffmpeg/flac with more recent version, or still haven't time ?

r0lZ

3rd November 2015, 10:42

I think at this point in time it's better to fail, because if dcadec sees a reason for a warning, this could still be a bug in dcadec (or a damaged audio file). It's better to force the user to double check, and maybe use ArcSoft instead, than to risk just writing a warning to the log which the user might simply not see, and then eventually produce a faulty audio file. After a couple more months or years, when we're more certain about dcadec being "bug free" or not, we can think about posting warnings and continuing decoding then. At least that's my opinion. Anyone having a different opinion?
Well, currently, only eac3to is unable to decode that picky DTSHDMA tracks. Even ffmpeg doesn't turn the strict decoding on, and has therefore no problem.

I agree that turning off the strict decoding mode is dangerous, but IMO, the "synchronisation error" reported (most probably erroneously) by DcaDec should be ignored. I don't know if it is possible to continue anyway after that error (and only that one), but if it's feasible, that could be a very good thing.

I have requested an option to turn the strict mode off via your bug tracker (here (http://bugs.madshi.net/view.php?id=358)), but honestly, I would prefer to leave that flag on, but have a workaround for what seems to be a bug in the DTS decoder. After having double-checked the original DTSHDMA and the conversions with other decoders, it seems that the streams are perfectly normal. Therefore, DcaDec with the strict option on is at least way too picky, at least for this specific error.

Also, note that some decoders do NOT stop after an extremely great number of synchronisation errors. It's the case when demuxing subtitles from some 3DBD (as reported in another bug on your tracker (http://bugs.madshi.net/view.php?id=87)). I see no reason to be much more tolerant with the subtitles than with the DTS tracks.

Anyway, a solution is necessary, but I'll be happy with just an option to turn the strict mode off, although I think it's not the best solution.

73ChargerFan

4th November 2015, 05:14

I have a DTSHDMA track causing the problem but unfortunately it is way too big (2.7 GB) to be uploaded

It'd be really useful to get that file to the developers if there really is a problem (i.e., it isn't just a bad rip or BD decode.)

That large of a file can be easily transferred between two computers both using utorrent, see How to Share Personal or Public Files Using uTorrent. (http://www.wikihow.com/Share-Personal-or-Public-Files-Using-uTorrent) It would be a private pseudo tracker run from your computer, and won't be publicly shared.

Or see the NetworkWorld article 19 free cloud storage options (http://www.networkworld.com/article/2932962/cloud-storage/19-free-cloud-storage-options.html).

r0lZ

4th November 2015, 10:12

I have already isolated the part causing the problem and posted it here (http://download.videohelp.com/r0lZ/tmp/DTS_HD_MAsync_bug_sample.dts). (See post #13582 (http://forum.doom9.org/showthread.php?p=1745182#post1745182).) In this case, there is no need to analyse the entire track. But thanks for the hints about transferring large files. I didn't know that "pseudo tracker" possibility of uTorrent. (BTW, I like also Infinit (https://infinit.io/) to share large files, but it requires to install a little program on your computer.)

ndjamena

11th November 2015, 04:25

madshi

11th November 2015, 09:09

OK, so I think I've fixed MediaInfo's issues with FLAC default layouts. I've also added "VALID_BITS" as a recognised tag and have moved it to the audio stream as "Valid bits".

I've removed HDCD if the value is zero... otherwise I've called it "High Definition Compatible Digital" and set it to "Yes"... Is that OK? Is it important to know if it's specifically tagged as NOT HDCD?

Is there anything else I should attempt to prepare MediaInfo to encounter?
Sounds good to me! FWIW, it might make sense to only list "valid bits" if it's less than the designated FLAC bitdepth. E.g. one common case is having 20bit in a 24bit container because FLAC doesn't support encoding a 20bit bitdepth, IIRC. I'd also ignore a 0 value for valid bits. Shouldn't occur in real life, but in theory it could be there for e.g. an audio track which has nothing but silence (zeroes) in it. I'm not a native english speaker btw, so maybe someone has a better idea how to name this in clear text? Not sure if "valid bits" is a good name.

I'd suggest to use "HDCD" as the name because that's the term everybody is familiar with. Writing "High Definition Compatible Digital" is like naming DVD "Digital Versatile Disc". Users would look at that three times and wonder what it means while "HDCD" is easy to recognize for anybody who knows what it is. eac3to always checks all audio tracks for HDCD, so if you find "HDCD" in the metadata, having it set to 0 usually means the track is *not* HDCD. But if you want to be extra safe that you're not reporting anything wrong then just reporting HDCD if it's set to "1" is fine, too.

IIRC, support for the "WAVEFORMATEXTENSIBLE_CHANNEL_MASK" is already available, right? At some point there was a problem with supporting "=0X" vs "=0x". Maybe you could double check that both is supported (you should simply ignore the case).

Thanks!

Music Fan

11th November 2015, 10:01

I read something astonishing about HDCD ;
http://forum.doom9.org/showthread.php?p=1612018#post1612018
HDCD can not be saved in .wav because sub channel will be lost.

Is it true ?

ndjamena

11th November 2015, 11:36

madshi

11th November 2015, 12:30

Actually, if I point mediainfo at a flac file before it's finish it DOES say '00" valid bits...
True, that's because eac3to only knows the final value after processing has run through. One more reason to ignore a value of 00... :p

HDCD... What about the people who don't know what it is?
Well, that's like saying that some people don't know what FLAC is, so you write "Free Lossless Audio Codec" instead of FLAC everywhere. But if you do that, most people who *DO* know what FLAC is will be confused, because although they know FLAC they might not know what the acronym stands for.

Just my 2 cents, of course. It's not really important to me. Just wanted to provide some feedback.

Zenitram

11th November 2015, 15:43

Sounds good to me! FWIW, it might make sense to only list "valid bits" if it's less than the designated FLAC bitdepth. E.g. one common case is having 20bit in a 24bit container because FLAC doesn't support encoding a 20bit bitdepth, IIRC. I'd also ignore a 0 value for valid bits.

Done (https://github.com/MediaArea/MediaInfoLib/commit/b117425dbaeefd513e5af58428731b3c9f4fa4b9).

Shouldn't occur in real life, but in theory it could be there for e.g. an audio track which has nothing but silence (zeroes) in it.

Hum... Not a good example. I hoped that this is not the implementation.
Silence with 16 valid bits is not same than silence with 24 valid bits, and this is not 0 bit of something (whatever is the name). So the value is expected to be the count of bits really used during quantization (https://en.wikipedia.org/wiki/Quantization_%28signal_processing%29) else this is only a 0 measurement (not useful).
Said another way, silence quantized at 20 bits then stored in the file as 24-bit should still have 20 valid bits in the metadata (this is the count of bits used by the digitilization tool), not 0. having only zeroes in the lowest bit does not mean that the bit is not valid (99.99999% chances it is, but in theory it is not), it may be valid (no luck, the source is with zeroes...).

True, that's because eac3to only knows the final value after processing has run through. One more reason to ignore a value of 00... :p

eac3to should know the bit depth of the input, scanning the lower bits of the full stream would be only a fallback if the input is known to provide invalid metadata (e.g. 24-bit FLAC which can be 20 or 24-bit in reality if I understand well). I understand the reason you prefer to scan the full file for checking lower bits but it may be misleading (e.g. in mathematics, 0.0000 means that it is between -0.00005 and 0.00004, it does not mean it is 0.000 or 0.00 or 0.0 or 0, which are true information but you lost the piece of information about precision).

I'm not a native english speaker btw, so maybe someone has a better idea how to name this in clear text? Not sure if "valid bits" is a good name.

SMPTE (https://en.wikipedia.org/wiki/Society_of_Motion_Picture_and_Television_Engineers) uses "Quantization bits" for this purpose in MXF (https://en.wikipedia.org/wiki/Material_Exchange_Format) file format.

In MediaInfo, I use "Bit depth" for the real value (your "valid bits") and "Stored bit depth" for the bit size in the file.

I'd suggest to use "HDCD" as the name because that's the term everybody is familiar with. Writing "High Definition Compatible Digital" is like naming DVD "Digital Versatile Disc".

I agree. Changed (https://github.com/MediaArea/MediaInfoLib/commit/1bb7de3a6ff9c1c822f0accca86cb4288381dc71).

HDCD... What about the people who don't know what it is? I didn't and had no idea why that tag was in all my encodes. That's why I thought it would be a good idea the give the full name.

As for FLAC or DVD, people put HDCD in Google and the first link is the Wikipedia page about "High Definition Compatible Digital".
Actually the acronym is more known by people able to help someone than the definition of the acronym.

IIRC, support for the "WAVEFORMATEXTENSIBLE_CHANNEL_MASK" is already available, right? At some point there was a problem with supporting "=0X" vs "=0x". Maybe you could double check that both is supported (you should simply ignore the case)

I don't remember exactly the previous behavior but ndjamena definitely fixed an issue with MediaInfo previous behavior, I have now more files with channels position. So I take his patch!

nevcairiel

11th November 2015, 16:04

Hum... Not a good example. I hoped that this is not the implementation.
Silence with 16 valid bits is not same than silence with 24 valid bits, and this is not 0 bit of something (whatever is the name). So the value is expected to be the count of bits really used during quantization (https://en.wikipedia.org/wiki/Quantization_%28signal_processing%29) else this is only a 0 measurement (not useful).
Said another way, silence quantized at 20 bits then stored in the file as 24-bit should still have 20 valid bits in the metadata (this is the count of bits used by the digitilization tool), not 0. having only zeroes in the lowest bit does not mean that the bit is not valid (99.99999% chances it is, but in theory it is not), it may be valid (no luck, the source is with zeroes...).

If you take a 20-bit signal, and you want to store it in a 24-bit format, what do you do? You pad it with zeroes.
Thats how its done everywhere, so you have no idea what the original bitdepth was when you get all zeroes, all the time.

Thats just a very common use-case when dealing with PCM, and eac3to wants to know if a signal was mastered wrong - since it occasionally happens that a 16-bit signal gets erroneously padded to 24-bit and encoded as such - with 8 LSBs all being zero.
Or in some cases, the format may not provide a way to signal some bitdepth - which is common for 20-bits. There is no harm to encode it as 24-bit in a lossless format, other than filesize, but the flag that it originally was 20-bit may be lost.

This is all long after quantization, and its all in perfectly accurate integer, not floating points. :)

madshi

11th November 2015, 16:22

If you take a 20-bit signal, and you want to store it in a 24-bit format, what do you do? You pad it with zeroes.
Thats how its done everywhere, so you have no idea what the original bitdepth was when you get all zeroes, all the time.

Thats just a very common use-case when dealing with PCM, and eac3to wants to know if a signal was mastered wrong - since it occasionally happens that a 16-bit signal gets erroneously padded to 24-bit and encoded as such - with 8 LSBs all being zero.
Or in some cases, the format may not provide a way to signal some bitdepth - which is common for 20-bits. There is no harm to encode it as 24-bit in a lossless format, other than filesize, but the flag that it originally was 20-bit may be lost.

This is all long after quantization, and its all in perfectly accurate integer, not floating points. :)
Exactly. The reason why I added the "VALID_BITS" tag in the first place was because many TrueHD and DTS-MA tracks are encoded as 24bit, but have a number of bits set to zero throughout the whole audio file. I've seen TrueHD/DTS-MA tracks detected by eac3to with anything between 16 and 24 bits (20 bits is common, but IIRC I've also seen e.g. 18bit or 22bit). Many tracks even have different bitdepths per channel! So this tag signals the number of bits that eac3to found to be set to non-zero anywhere throughout the audio file. Whether this information is considered useful by anybody or not is an entirely different question. But this is how VALID_BITS has always been "meant" by eac3to.

Maybe I should have named it "NON_ZERO_BITS". But to be honest, all those years ago when I added this tag I considered it a "private" eac3to flag and didn't think anybody would be interested in reading/displaying it.

Zenitram

11th November 2015, 16:23

If you take a 20-bit signal, and you want to store it in a 24-bit format, what do you do? You pad it with zeroes.

Please read again my comment (especially the example with silence), I don't say something else.
I just say that this is not bidirectionnal i.e. zeroes in the lowest bits does not means that this was a 20-bit signal for sure (it may be a 24-bit format with zeroes in reality), you can just say that there is 99.9999% chances that this is the case.
Silence is a good example: silence, all bits 0 everywhere, that does not mean that 0 bits are valid. Same with a square signal.

And as I also said, I understand the reason it is made, but this is not a reason for changing reality of mathematics, and relying on only this check is not perfect. If you can rely on something else (e.g. metadata) please priotize this method over zeroes checking (zeroes checking should be only a fallback in the case there is not such metadata)

Zenitram

11th November 2015, 16:25

So this tag signals the number of bits that eac3to found to be set to non-zero anywhere throughout the audio file. Whether this information is considered useful by anybody or not is an entirely different question. But this is how VALID_BITS has always been "meant" by eac3to.

Maybe I should have named it "NON_ZERO_BITS". But to be honest, all those years ago when I added this tag I considered it a "private" eac3to flag and didn't think anybody would be interested in reading/displaying it.

Got it. "VALID" term was something misleading for me, I'll change the behavior of my own tool when I detect such tag.

madshi

11th November 2015, 16:26

Thanks!

nevcairiel

11th November 2015, 16:29

And as I also said, I understand the reason it is made, but this is not a reason for changing reality of mathematics, and relying on only this check is not perfect. If you can rely on something else (e.g. metadata) please priotize this method over zeroes checking (zeroes checking should be only a fallback in the case there is not such metadata)

Well it really comes down to one simple argument:

Zeroes in the LSBs are useless ("empty" information), and therefor if metadata says 24-bit, but the signal consistently has 8 bits of zero at the end, can encode as 16-bit, save space, lose no signal information at all.
That seems really the information that madshi/eac3to is after.

Zenitram

11th November 2015, 16:34

Zeroes in the LSBs are useless

They are not. as 0 does not say the same thing as 0.0000 (and yes, quantization bits are similar to float).
I understand this is same for your ears, but it may be different for some compression algorithm and/or for people looking for the count of bits used for quantization (again, zeroes with 16-bit is not same as zeroes with 24-bit, zeroes with 24-bit quantization say that this is more sure that it is silence for real)

It is all about precision information, I understand that you don't care, but that does not mean it is useless for everybody. It is very important for a couple of people I work for.

73ChargerFan

11th November 2015, 21:16

ndjamena

12th November 2015, 03:19

I'm glad to see MediaInfo will recognize HDCD; now I can script a test for it and mark such albums in my collection. Thanks.

https://upload.wikimedia.org/wikipedia/en/thumb/4/4f/HDCD_logo.svg/148px-HDCD_logo.svg.png

It doesn't literally "detect" HDCD, it just reads a tag EAC3To has been adding to the FLAC files it produces.

If you have a HDCD FLAC/ALAC/WAVPACK file that DOESN'T have the tag MediaInfo will not detect it.

In that case, you could run your files through EAC3To or Foobar and get the tags added/add them yourself.

(MediaInfo has always displayed the HDCP tag, it just attached it to the file rather than the stream which means the tag was discarded if it was muxed into a Matroska file.)

Music Fan

12th November 2015, 10:38

Zenitram

12th November 2015, 10:50

You don't seem to be interested by the information I mentioned yesterday, your HDCD files are maybe not really HDCD, look at the link I gave in this post ;
http://forum.doom9.org/showthread.php?p=1746126#post1746126

And there is a link to a post saying that this is not correct (http://www.head-fi.org/t/151329/hdcd-technology-in-detales#post_11243554).
And now?

Music Fan

12th November 2015, 11:16

Interesting, this guy is not 100 % certain about it but he has good arguments.
If he is right, I wonder why MvB heard differences between the 2 ripping methods (with and without subchannels), admitting he was honest and not trying to discourage people to copy HDCDs.

madshi

12th November 2015, 11:23

FWIW, eac3to contains a user written HDCD decoder which seems to work just fine on WAV source files. I've no idea how the HDCD decoder works internally, though, nor can I guarantee whether it's 100% complete and accurate.

Music Fan

12th November 2015, 11:33

Ok, I never tried to decode HDCD files with eac3to, I guess the goal is to produce 24bit wav to keep HDCD quality without needing HDCD player ; in this case, one shouldn't specify the command -down16, right ?

madshi

12th November 2015, 11:39

If your target is lossless, eac3to by default doesn't decode HDCD, but leaves it untouched, so input and output bitdepth stays at 16bit. You can force HDCD decoding by using the "-decodeHdcd" switch. Or if you transcode to a lossy format, eac3to automatically decodes HDCD, so that the input to the lossy decoder has the highest possible quality. If you want to decode HDCD, and preserve its full quality, "-down16" is obviously not a good idea.

Music Fan

12th November 2015, 11:51

If your target is lossless, eac3to by default doesn't decode HDCD, but leaves it untouched, so input and output bitdepth stays at 16bit.
In this case, why to use eac3to with HDCD wavs ?
If one needs Flac, I guess the HDCD information will be lost (except if -decodeHdcd is used and -down16 is not, therefore you get 24 bit Flac with HDCD quality).

If you want to decode HDCD, and preserve its full quality, "-down16" is obviously not a good idea.
Ok, does its full quality correspond to 20 or 24 bit ?

madshi

12th November 2015, 12:02

Why would HDCD get lost when using FLAC? It doesn't. FLAC is lossless.

Music Fan

12th November 2015, 12:09

Do you mean that if -decodeHdcd is NOT used, and if the target format is Flac 16 bit, the Flac will still include the HDCD information that can be decoded as HDCD Flac ?

madshi

12th November 2015, 12:16

That's what I just said.

Music Fan

12th November 2015, 12:25

I'm surprised because I wonder how the HDCD information -which is done for LPCM- can be kept in Flac.
IIRC, HDCD encoding use random bits and I don't see how a FLac encoder can recognize this kind of pattern and keep it. It is lossless, ok, but its structure is different than LPCM.

madshi

12th November 2015, 12:38

What part of "lossless" do you not understand? FLAC is like a zipped WAV/LPCM file.

ndjamena

12th November 2015, 12:39

http://www.audiomisc.co.uk/HFN/HDCD/Enigma.html
https://en.wikipedia.org/wiki/Compact_Disc_Digital_Audio

It's possible he's right. CD's aren't strictly LPCM, they have a variable gain control.

Some CDs are mastered with pre-emphasis, an artificial boost of high audio frequencies. The pre-emphasis improves the apparent signal-to-noise ratio by making better use of the channel's dynamic range. On playback, the player applies a de-emphasis filter to restore the frequency response curve to an overall flat one. Pre-emphasis time constants are 50µs and 15µs (9.49 dB boost at 20kHz), and a binary flag in the disc subcode instructs the player to apply de-emphasis filtering if appropriate. Playback of such discs in a computer or 'ripping' to wave files typically does not take into account the pre-emphasis, so such files play back with a distorted frequency response.[

Music Fan

12th November 2015, 14:48

Interesting. But I believe HDCD and CD with De-emphasis are 2 different things and thus need different ripping method.
Anyway, I kept searching informations and it seems that when ripping HDCDs in a simple way (copying waves instead of making ISO keeping cd's sub channels), a part of the needed information to decode properly HDCD is not retained.
I found a post that summarizes clearly everything I read on this subject ;
http://forums.stevehoffman.tv/threads/standalone-hdcd-decoder.224268/#post-5695519
Foobar2000 and dBpoweramp HDCD detection & decoding are based on HDCD.exe, which was created by emulating Windows Media Player. What WMP does not do (and consequently, neither does HDCD.exe) is decode the transient filter function. Although, it can detect it.
And the transient filter information is apparently in the sub channels I evoked earlier.

It means that the HDCD conversion is done but not exactly how it should be.

madshi

12th November 2015, 15:01

Regardless of whether that's true or not, none of this has anything to do with eac3to, because eac3to does not rip CDs or ISOs. eac3to does the best it can with the data it gets. If something is lost when ripping a CD to WAV then this loss has happened before eac3to was involved. There is no (further?) loss when using eac3to, as long as the audio data is kept lossless. So this is my last post about this topic.

Music Fan

12th November 2015, 22:56

I don't really understand your reaction because as your program is supposed to decode HDCD, and if you are curious about all that stuff (and I guess you are, otherwise you wouldn't have created this tool), you should be happy to learn these things and maybe thank people who take time to understand how your tool handle a particular format and make research about it.
People who use your program deserve to know its limits which should be clearly mentioned on this topic or in the help of eac3to.

Thunderbolt8

12th November 2015, 23:04

eac3tos was created to be able to decode/deal with HD movies and their audio tracks. HDCD is not really part of that.

Yoshi

13th November 2015, 23:58

eac3to v3.30 released

http://madshi.net/eac3to.zip

* libDcaDec is now default for all DTS tracks except XSA / low bitrate

At least for two Blu-ray sources I already encountered after converting stuff for not even a day, this turns out to be a bad mistake:

In the case of the US release of "Ex Machina", the libDca decoder produces bad clipping and with the German release of "Still Alice", it produces white noise on all channels instead of the movie soundtrack. :(

Here you can see three times the left channel of the "Ex Machina" 7.1 DTS-HD MA source - 1. processed with eac3to and decoded by the ArcSoft decoder (1.1.0.7), 2. processed with eac3to and decoded by the libDca decoder and 3. processed with MakeMKV and decoded by the libDca decoder.

http://img5.fotos-hochladen.net/uploads/arcsoftvslibx4z5lo69rf.jpg

The first waveform is clipped as well, but this is most likely already contained in the source - the usual nowadays mastering stupidity. :( The second and third are identical, so it's obvious whose fault this is.

Maybe I missed something but did anyone actually test that libdca crap before deciding to use it? :angry:

Same question to the MakeMKV developers which seem to have fallen into the same trap. At least, eac3to can be forced to still use the ArcSoft-decoder.

nevcairiel

14th November 2015, 00:10

You should first stay calm and not result to insulting peoples hard work in providing a free and open decoder for a format thats been hard to handle completely for a long a time.
Of course its tested, but not every edge case can be thoroughly covered without access to every single disc on the planet, and if the source has baked in clipping, it could result in all sorts of problems - like this. Clearly clipping behavior can be improved by simply flat-lining the clipping instead of overflowing it, but I even saw a change related to that in newer libdcadec versions, so maybe its already resolved, just eac3to not updated yet.

On top of all that, if you can provide a short sample that illustrates such a problem, the developers will likely be happy to investigate and resolve these issues.

ndjamena

14th November 2015, 00:17

EAC3To should probably detect that and then run a second pass to normalise it, something that's probably not possible with Arcsoft.

libDcaDec is open source so can be modified, maybe to output 32 bit.

But the problem in this case is obviously in the audio stream itself.

Yoshi

14th November 2015, 00:36

You should first stay calm and not result to insulting peoples hard work in providing a free and open decoder for a format thats been hard to handle completely for a long a time.

My excuses, you're right. This was written right out of frustration about the screwed up rips which resulted in using the decoder which is supposed to replace the commercial add-ins required before. And to be fair, the ArcSoft decoder - depending on the version - isn't "perfect" either, at least with eac3to (the MakeMKV creators claim that by addressing the library directly, there are no issues at all with it, including 'strange 7.1 setups').

Of course its tested, but not every edge case can be thoroughly covered without access to every single disc on the planet, and if the source has baked in clipping, it could result in all sorts of problems - like this.

Sorry, but with all due respect to all the developers and their hard work - we are talking about a lossless codec system here. DTS-HD MA might me more complex due to its core and extension architecture, but for a proper decoder dealing with a lossless format, it must not matter one bit how screwed up the source is content-wise, meaning the raw PCM source, not damaged frames or headers which might lead to problems. In the latter case, one decoder might indeed be more tolerant than the other. Clipping in the source is not an excuse for a lossless decoder to mess up the resulting PCM completely.

If a decoder doesn't reproduce the original data of a losslessly encoded source, then it's faulty. There is absolutely no tolerance to that.

Clearly clipping behavior can be improved by simply flat-lining the clipping instead of overflowing it, but I even saw a change related to that in newer libdcadec versions, so maybe its already resolved, just eac3to not updated yet.

As I stated above, I don't see the tolerance of a lossless decoder regarding the reproduction of the PCM source.

On top of all that, if you can provide a short sample that illustrates such a problem, the developers will likely be happy to investigate and resolve these issues.

I'm certainly willing to contribute here, otherwise I wouldn't take the effort to compare and make screenshots. :cool:

nevcairiel

14th November 2015, 00:49

Sorry, but with all due respect to all the developers and their hard work - we are talking about a lossless codec system here. DTS-HD MA might me more complex due to its core and extension architecture, but for a proper decoder dealing with a lossless format, it must not matter one bit how screwed up the source is content-wise, meaning the raw PCM source, not damaged frames or headers which might lead to problems. In the latter case, one decoder might indeed be more tolerant than the other. Clipping in the source is not an excuse for a lossless decoder to mess up the resulting PCM completely.

Unfortunately, its not quite as simple as that. Without having the PCM source, we don't know what is "lossless", and when there is baked in clipping like this, its possible that no decoder is going to produce an exact copy of the source, since before encoding, it may not have had this clipping (maybe because it was higher bitdepth, somehow).

The problem in your screenshots is a simple one really. The decoder decodes the signal perfectly, its just that the decoded signal does not fit into the defined integer range and instead "wraps" into negative (just how integers work, too high positive numbers suddenly turn negative).
You can actually see the waveform "continue" in the negative - which clearly sounds terrible, but it gives us strong hints to whats going on.

So, the answer is instead of decoding it "perfectly", to actually clip the signal after decoding, so you get flatlines instead. Unfortunately a lot of information about DTS-HD MA has to be reverse engineered or "guessed" based on the behavior of other decoders, like ArcSoft.

So in short, the best we can do is "lossless to ArcSoft", or any other reference decoder, since thats the only data points we have (unless someone can encode something with such a problem and provide the original PCM)
Clearly this is a bug, and should be fixed, but I find it important to clarify a bit on how it came to be.

Anyway, like I mentioned earlier, a change was already performed in libdcadec to perform more aggressive clipping, which may just handle this particular sample already.
If you can cut a small segment with the problematic areas from the two Blu-rays you have been having issues with, we can make sure, and/or get them fixed - and test losslessness to ArcSoft after any potential fixes.

Its everyones goal here to provide proper "lossless" decoding on all sorts of broken samples, of course.

Yoshi

14th November 2015, 01:29

Unfortunately, its not quite as simple as that. Without having the PCM source, we don't know what is "lossless", and when there is baked in clipping like this, its possible that no decoder is going to produce an exact copy of the source, since before encoding, it may not have had this clipping (maybe because it was higher bitdepth, somehow).

Very interesting remarks. I have to admit that I'm not familiar with the internal structure of the encoding and decoding process of DTS-HD(MA) in detail except for the core and extension concept. If I understand you correctly, there might be inputs, DTS-HD(MA) won't be able to handle properly. To my best understanding, this goes against all what makes up a lossless codec in the first place. Maybe a sacrifice of making DTS backward-compatible this way.

But let's leave source-clipping aside and have a look what libDca does to the calm and innocent intro of "Still Alice" instead. ;)

http://img5.fotos-hochladen.net/uploads/arcsoftvslib5knl6o21uv.jpg

Regarding the test files, I'll send you a PM shortly.

nevcairiel

14th November 2015, 01:32

That one sure is weird. Will be interesting to see. ;)

torturesauce

14th November 2015, 01:36

Ex Machina has a new codec called DTS:X (not to be confused with DTS Headphone:X, which is also included on the disc). It is the rival format to Dolby Atmos. Therefore, the DTS-HD MA 7.1 is actually the core track. More info here: http://www.blu-ray.com/movies/Ex-Machina-Blu-ray/128113/#Review

Maybe this is the reason libdcadec produces inaccurate results?

ndjamena

14th November 2015, 01:50

Turbo:

MKV, 1 video track, 1 audio track, 1:35:41, 24p /1.001
1: h264/AVC, English, 1080p24 /1.001 (16:9)
2: DTS Master Audio, English, 7.1 (strange setup) channels, 24 bits, 48kHz
(core: DTS-ES, 5.1 channels, 1509kbps, 48kHz)
With the core extracted:

MKV, 1 video track, 1 audio track, 1:35:41, 24p /1.001
1: h264/AVC, English, 1080p24 /1.001 (16:9)
2: DTS-ES, English, 5.1 channels, 1509kbps, 48kHz

So... when is DTS-ES still regular 5.1...

...or is this likely a bug in the DTS encoder suite?

ndjamena

14th November 2015, 01:53

ndjamena

14th November 2015, 02:02

Very interesting remarks. I have to admit that I'm not familiar with the internal structure of the encoding and decoding process of DTS-HD(MA) in detail except for the core and extension concept. If I understand you correctly, there might be inputs, DTS-HD(MA) won't be able to handle properly. To my best understanding, this goes against all what makes up a lossless codec in the first place. Maybe a sacrifice of making DTS backward-compatible this way.

But let's leave source-clipping aside and have a look what libDca does to the calm and innocent intro of "Still Alice" instead. ;)

http://img5.fotos-hochladen.net/uploads/arcsoftvslib5knl6o21uv.jpg

Regarding the test files, I'll send you a PM shortly.

This second one looks like it's been amplified. Far too much gain has been applied.

nevcairiel

14th November 2015, 02:28

But let's leave source-clipping aside and have a look what libDca does to the calm and innocent intro of "Still Alice" instead. ;)

It seems to switch from 16-bit to 24-bit decoding here along the way, probably due to a change in the bitstream. It almost seems like eac3to doesn't handle this case properly, and not dcadec.
I have let madshi know so he can chime in here.

Other software using libdcadec like my own LAV Filters or ffmpeg can decode this file fine.

NikosD

14th November 2015, 09:33

Puzzled about this TrueHD sample:
https://www.sendspace.com/file/6cn8ub

I tried to convert it to AC3 using eac3to v3.30 source.thd dest.ac3 and the app crashed

TrueHD, 5.1 channels, 48kHz, dialnorm: -27dB
Removing TrueHD dialog normalization...
Decoding with libav/ffmpeg...
Remapping channels...
Encoding AC3 <640kbps> with libAften...
Initialization of the AC3 encoder failed.
Aborted at file position 262144.

Using eac3to v3.29 source.thd dest.ac3 works fine.

TrueHD, 5.1 channels, 48kHz, dialnorm: -27dB
thd, 48000, 5.1
Removing TrueHD dialog normalization...
Decoding with libav/ffmpeg...
Remapping channels...
Encoding AC3 <640kbps> with libAften...
Creating file "test329.ac3"...
The original audio track has a constant bit depth of 16 bits.
eac3to processing took 9 seconds.
Done.

nevcairiel

14th November 2015, 11:06

In the case of the US release of "Ex Machina", the libDca decoder produces bad clipping

I checked a sample provided by Yoshi of this track, and the new libdcadec version produces a bit-identical result to ArcSoft, so as I suspected the clipping issue was already fixed. Just needs an updated version of eac3to with a new dcadec.

SeeMoreDigital

14th November 2015, 11:22

Puzzled about this TrueHD sample:
https://www.sendspace.com/file/6cn8ub

I tried to convert it to AC3 using eac3to v3.30 source.thd dest.ac3 and the app crashed

Using eac3to v3.29 source.thd dest.ac3 works fine.

I'm able to confirm this observation too, using your TrueHD sample...

Boulder

14th November 2015, 11:30

nevcairiel

14th November 2015, 11:54

Is it possible to build libdcadec.dll outside of eac3to?

I suppose it is, if its an unmodified version, which it probably is.

madshi

14th November 2015, 12:02

Yes, it is, but the dcadec interface changed a bit, allowing warnings now instead of errors. Anyway, I'll release a new build with an updated dcadec soon.

Yoshi

14th November 2015, 12:41

I checked a sample provided by Yoshi of this track, and the new libdcadec version produces a bit-identical result to ArcSoft, so as I suspected the clipping issue was already fixed. Just needs an updated version of eac3to with a new dcadec.

Many thanks for checking on this! After you successfully irritated me regarding how lossless lossless can be when dealing with essentially unknown sources (mixes) - what's the consensus, is the nominally correct (identical) PCM-result of libDca and ArcSoft considered to be the true reproduction or not?

The clipping which occurs in the "correct" result is probably already contained in the mix or mastering, isn't it?

@all: since the most recent version of MakeMKV produces the same faulty results, I tried to contact "mike" which seems to be the developer or at least part of the team. Stupidly, I can't register at that forum since my IP range is blocked for some reason which is beyond me.

Just in case, anyone knows if and how to enforce MakeMKV to enforce to still use the dtsdecoder.dll instead of the integrated libDca.

nevcairiel

14th November 2015, 13:07

Many thanks for checking on this! After you successfully irritated me regarding how lossless lossless can be when dealing with essentially unknown sources (mixes) - what's the consensus, is the nominally correct (identical) PCM-result of libDca and ArcSoft considered to be the true reproduction or not?

The clipping which occurs in the "correct" result is probably already contained in the mix or mastering, isn't it?

It seems to be possible to retrieve the audio without clipping by reducing the overall volume in this particular sample, if thats the desired goal is another question.
From what I understand, madshi wants to offer a two-pass option in eac3to to reduce the volume and re-process the file if such clipping issues are detected. It wouldn't be bitexact to ArcSoft or the source, but probably be better than clipping!

Yoshi

14th November 2015, 14:00

I don't understand this.

This is with that required volume reduction in general.

I'm aware of eac3to's two-pass-feature and understand the requirement for volume reduction depending on the source when downmixing a number of channels into fewer channels than the source since all channels could carry 0dBFS and have to fit into the lower range.

What I never understood is why this is sometimes required when dealing with lossy codecs without downmixing as I don't see the point why I have to reduce the volume just to reconstruct the lossy source.

Now with lossy codecs, you got transformation into the frequency domain and stuff and maybe due to errors introduced by the psychoacoustic model, you might get (intersample) peaks here and there asking for a few additional dB of headroom but why this shall still be an issue with lossless sources is beyond me.

By definition, there can be only one correct PCM result and audio level for any given lossless source. If that clipped, so shall the PCM of course. When lowering the decoded audio level for a clipped lossless source, I would expect the decoded result to clip as well at -x dBFS then, gaining nothing but slightly rising the noise level due to the lower SNR.

nevcairiel

14th November 2015, 14:08

Its probably just a mistake when encoding. Formats like DTS-HD are a bit more complex than a simple codec like FLAC, they have embedded downmixes for stereo and 5.1 and whatnot (and the decoder performs something called "downmix reversal" to get the 7.1 signal), so when all these features are used, its apparently easy enough to screw something up.

I'm sure there are also lossless encodes where the clipping is part of the original PCM, but in this particular sample it is possible to retrieve the audio without clipping, albeit at a slightly reduced volume to make room for the extra data.

Thunderbolt8

14th November 2015, 14:22

just to confirm, the US Blu-ray of Ex-Machina has indeed a 7.1 DTS:X (+ a DTS:X headphone) track. so this is perhaps why anything else than just extracting the track (well at least if this works as it should) could potentially result in non lossless output as the reis probably no support yet for these kind of tracks via libDAC or arcsoft (unless there are recent updates for arcsoft)

I checked a sample provided by Yoshi of this track, and the new libdcadec version produces a bit-identical result to ArcSoft, so as I suspected the clipping issue was already fixed. Just needs an updated version of eac3to with a new dcadec.just asking, does that mean that full DTS:X track processing is possible now with that version? or that just one specific error has been fixed?

nevcairiel

14th November 2015, 14:34

There are no decoders for DTS:X outside of the hardware receivers.
Note that such things as "bitexact" don't really apply to concepts like DTS:X or Dolby Atmos, as they are designed to be mixed for the speaker setup of the user, so there is no one correct way to "decode" it.

Thunderbolt8

14th November 2015, 14:42

so if you want to have the full Atmos and DTS:X information from an audio track, the only thing which makes sense is to extract the entire track and bitstream it to you receiver, correct?

NikosD

14th November 2015, 14:42

@madshi
@tebasuna51
@nevcairiel

Any comments on my TrueHD sample and AC3 conversion ?

Is it a bug of v3.30 ?

nevcairiel

14th November 2015, 14:44

so if you want to have the full Atmos and DTS:X information from an audio track, the only thing which makes sense is to extract the entire track and bitstream it to you receiver, correct?

Yes, you should always leave the track intact. Even if some day a software decoder appears, it'll still be the same deal - you need to tell it how your speakers are setup to mix the extra "3D" audio properly, so it should only do this conversion at playback time, and not when re-encoding.

madshi

14th November 2015, 16:21

eac3to v3.31 released

http://madshi.net/eac3to.zip

* libDcaDec: updated to latest build
* libDcaDec: decoding only aborts on critical issues now
* libDcaDec: now reports warnings if something isn't 100% perfect
* libDcaDec: proper handling of clipped files (2nd pass etc)
* libDcaDec: proper handling of tracks that switch bitdepth 16 <-> 24
* fixed: TrueHD decoding -> AC3 encoding didn't work properly

Thunderbolt8

14th November 2015, 16:31

whats the relation between the bitdepth switch fix and your re-opening of that topic at dcadec github?

Boulder

14th November 2015, 16:33

eac3to v3.31 released
Thanks, madshi!

madshi

14th November 2015, 16:37

whats the relation between the bitdepth switch fix and your re-opening of that topic at dcadec github?
I did what I could do in eac3to to handle all possible situations correctly. There *may* still be something minor to fix in dcadec but nothing dramatic.

Boulder

14th November 2015, 16:44

madshi

14th November 2015, 16:49

Not sure about 3.29, that's too old.

nevcairiel

14th November 2015, 16:53

Is dcadec now more accurate what comes to errors while decoding? I tested the new version on a stream which had no errors with v3.29, the new version reports "libDcaDec reported the warning "XLL output not lossless"." while decoding. I don't know if it's related to this, but in this case I have a DTS-HD MA track which is reported as 24 bits but contains only 16-bit data.

"not lossless" warnings appear on totally valid streams sometimes, its just a thing about how the format works when its stitched together on clip boundaries or things like that.
Decoding of these parts didn't change, it now simply outputs a warning instead of silently ignoring such cases.

Boulder

14th November 2015, 16:57

Not sure about 3.29, that's too old.Tested with v3.30 as well, the same thing (it doesn't report anything).

If you (or the dcadec dev) want to see the source track, I can provide it. It's a stereo track so it doesn't require a huge amount of space.

EDIT: just read nevcairiel's explanation. Makes perfect sense :)

NikosD

14th November 2015, 17:09

eac3to v3.31 released

http://madshi.net/eac3to.zip

* fixed: TrueHD decoding -> AC3 encoding didn't work properly

Thanks.

It works now.

Thunderbolt8

14th November 2015, 17:10

can DTS:X (headphone) tracks be delayed? is there any way to implement atmos tracks being able to be delayed?

GZZ

14th November 2015, 21:58

is there anyway to control the compression level when encoding to Flac ?

SeeMoreDigital

14th November 2015, 22:03

eac3to v3.31 released

http://madshi.net/eac3to.zip

* fixed: TrueHD decoding -> AC3 encoding didn't work properly
Many thanks :)

Sparktank

15th November 2015, 06:54

The updates have been very enterprising lately. :)

73ChargerFan

15th November 2015, 08:23

is there anyway to control the compression level when encoding to Flac ?
See this post (http://forum.doom9.org/showthread.php?p=1742284#post1742284) or search this thread to see other answers.

r0lZ

15th November 2015, 11:35

... the dcadec interface changed a bit, allowing warnings now instead of errors.
eac3to v3.31 released

http://madshi.net/eac3to.zip

* libDcaDec: updated to latest build
* libDcaDec: decoding only aborts on critical issues now
* libDcaDec: now reports warnings if something isn't 100% perfect
* libDcaDec: proper handling of clipped files (2nd pass etc)
* libDcaDec: proper handling of tracks that switch bitdepth 16 <-> 24
* fixed: TrueHD decoding -> AC3 encoding didn't work properly
Thanks for the update. I confirm that the new version no longer aborts with a Synchronisation error when converting some DTS-HD-MA tracks. (DcaDec "strict mode" problem reported here (http://forum.doom9.org/showthread.php?p=1745158#post1745158) and here (https://github.com/foo86/dcadec/issues/38#issuecomment-153026239).) Now, only a warning is printed to the log. It's perfect! Thanks!

Madshi, just to be sure, the option I've requested via your bug tracker (here (http://bugs.madshi.net/view.php?id=358)) to turn off the strict mode doesn't seem to be implemented. I suppose that it is not necessary any more, because now eac3to can distinguish a warning from a fatal error, and doesn't stop any more when it's not absolutely necessary, but you have closed the request with the message "Implemented in v3.31." Does it mean that there is a new option to turn off the strict mode? In that case, what is its syntax? Or have you abandoned the idea of the option because it is not longer necessary to implement it?

Anyway, it's only a theoretical question. I suppose I don't need that option any more. Thanks again for the update. :-)

madshi

15th November 2015, 11:40

can DTS:X (headphone) tracks be delayed? is there any way to implement atmos tracks being able to be delayed?
There's nothing special about DTS:X or Atmos tracks. DTS tracks can be delayed, with or without DTS:X. TrueHD cannot, with or without Atmos.

just to be sure, the option I've requested via your bug tracker (here (http://bugs.madshi.net/view.php?id=358)) to turn off the strict mode doesn't seem to be implemented.
There isn't really an option, I simply replaced the whole logic by "abort only on critical errors, post warnings for non-critical stuff", which only the very latest dcadec version supports.

ndjamena

15th November 2015, 14:23

Jerome is in the middle of giving proper output for DTS ES tracks in MediaInfo... while he's at it, does anyone have a sample of a DTS:X header they'd be willing to share?

r0lZ

15th November 2015, 14:42

There isn't really an option, I simply replaced the whole logic by "abort only on critical errors, post warnings for non-critical stuff", which only the very latest dcadec version supports.
OK, it's indeed the best solution. Thanks again. :-)

SeeMoreDigital

15th November 2015, 15:22

... while he's at it, does anyone have a sample of a DTS:X header they'd be willing to share?
If it helps, here's a 10 second (m2ts) sample cut off the beginning of Ex Machina: https://www.sendspace.com/file/4cw0yj

Cheers

Zenitram

15th November 2015, 15:46

If it helps, here's a 10 second (m2ts) sample cut off the beginning of Ex Machina

I don't find an obvious method for detecting DTS:X in that DTS stream, it loooks like a classic DTS-MA file (and eac3to detects it as such too) but I don't implement the whole available DTS spec so maybe I miss something (anyway, the latest DTS spec has no tip about DTS:X :( ).
Any clue about how to detect DTS:X feature in the extension part of the DTS stream?

Edit Found how to do, thanks to dcadec guy (https://github.com/foo86/dcadec/issues/37)

ndjamena

15th November 2015, 16:50

Apparently a bunch of the Pixar movies and others have DTS ES Matrixed DTS-MA 5.1.

Would anyone see any point in EAC3To adding an "ES" tag to the FLAC files output from these movies?

Yoshi

15th November 2015, 18:01

I'm sure there are also lossless encodes where the clipping is part of the original PCM, but in this particular sample it is possible to retrieve the audio without clipping, albeit at a slightly reduced volume to make room for the extra data.

How did you retrieve the audio from Ex Machina without clipping? When I apply the -3dB option with eac3to for instance, I get the same clipped result, only at -3dBFS of course.

madshi

15th November 2015, 18:24

How did you retrieve the audio from Ex Machina without clipping? When I apply the -3dB option with eac3to for instance, I get the same clipped result, only at -3dBFS of course.
The latest eac3to 3.31 should automatically fix the clipping, without needing you to use any options.

Yoshi

15th November 2015, 19:09

Many thanks madshi for your support and hint!

I had used the Arcsoft-decoder with your new version of eac3to, switched back to libDca and now it works as you described.

However, my real problem now is my lack of understanding why it clips with the Arcsoft-decoder but doesn't with the bugfixed libDca-decoder:

http://img5.fotos-hochladen.net/uploads/clippingdj13yki0q4.jpg

Obviously, if libDca is able to recontruct the wave form, the clipping wasn't contained in the source as I assumed first.

Furthermore, eac3to doesn't report any clipping when using the Arcsoft decoder, which - so far - made perfectly sense to me since I logically assumed that when dealing with (I repeat myself, I know) lossless codecs, any clipping which might be encountered in the decoded PCM must have been already part of the source, thus any reduction in loudness level wouldn't give anything (except for intersample peak clipping during D/A-conversion, but that's a topic on its own).

How does eac3to actually sense any clipping at all? Does it analyse the decoded PCM and count successive samples at 0dBFS like many audio editors do it or does it rely on the feedback of the decoders?

Since once clipped, it's impossible to reconstruct anything beyond that point, the level reduction, eac3to performs must occur before decoding, am I right? It probably instructs the decoder to decode the stuff to PCM at a lower level. But why don't the decoders to this on their own? Because they are meant to be used at realtime and hence no 2nd pass is possible, so better clip than being too quiet?*

How much do I have to worry for already converted DTS-HD MA sources by the Arcsoft decoder now? Is Ex Machina a rare "clipping exception" due to its underlying DTS-X-stuff?

I mean, after all, isn't it totally frustrating to deal with lossless codecs just to realize that in not that few cases, it isn't? For me, it is!

*An additional thought: if the clipping can't be generally avoided without 2nd-pass-decoding, how does a stand-alone AV-receiver with all the newest gizmo-support (Dolby Atmos, DTS-X, bla bla codec) do it then? How does the signal look like after its "super officially licensed" decoder before the DAC is fed with it?

madshi

15th November 2015, 19:45

eac3to can detect and fix clipping when using libdcadec because libdcadec outputs its decoded samples in 32bit, so there's a lot of headroom to allow clipping to be transported from libdcadec to eac3to. ArcSoft is different, but it's a long time since I looked into the ArcSoft API. Maybe there'd be some way to detect clipping there, too, although I doubt it. In any case, it works with libdcadec, which is now the default decoder, so I don't really have much interest in improving the ArcSoft decoder.

I've no idea how many DTS-MA tracks might have clipping baked in, as Ex Machina does, so I can't comment on whether you need to rerip them or not. I would guess it's probably rare. Maybe it's a side effect of DTS:X, maybe the encoder is not bug free yet, but I really don't know.

DTS supports some sort of dialnorm processing. It's possible that receivers who perform dialnorm processing might avoid the clipping, but I doubt it. I think probably receivers would play Ex Machina clipped. But again I'm guessing, I've no idea.

Lowering volume results in floating point values, which means dithering needs to be applied. This is *not* perfectly lossless, and the compression efficiency goes down dramatically. So lowering volume is not recommend, unless it's absolutely necessary.

Thunderbolt8

15th November 2015, 21:04

I am decoding a 1.0 DTS-HD MA track to .wav and now the get info line "libDcaDec reported the warning 'XLL output not lossless'".

what does that mean and how is this relevant for me? does it mean that the track or the conversion is not lossless after all in this case?

edit: have to add theres the information "Original audio track: max 24 bits, average 16 bits, most common 16 bits." at the end of the decoding process. does that mean that this warning is now the default message in case of these mixed bitdepth audio tracks, meaning just to tell us that this track is no real/full 24-bit track, but fine and lossless otherwise?

Yoshi

15th November 2015, 21:13

"not lossless" warnings appear on totally valid streams sometimes, its just a thing about how the format works when its stitched together on clip boundaries or things like that.
Decoding of these parts didn't change, it now simply outputs a warning instead of silently ignoring such cases.

I can confirm this kind of warning with "Bates Motel Season 3" as well (DTS-HD MA 5.1). The result is bit identical to Arcsoft's output, though.

eac3to can detect and fix clipping when using libdcadec because libdcadec outputs its decoded samples in 32bit, so there's a lot of headroom to allow clipping to be transported from libdcadec to eac3to.

For me, this arises the question of what word-length the original source had during mastering/authoring in the studio. I thought that the maximum they feed the DTS encoders with would be 24-bit-PCM. :confused:

In any case, it works with libdcadec, which is now the default decoder, so I don't really have much interest in improving the ArcSoft decoder.

However, it seems to be advisable to consider it as some sort of backup/reference in addition. After all, libdca doesn't seem to be perfect either. I mean, one bug fixed, yet the next one to be discovered. :sly:

I've no idea how many DTS-MA tracks might have clipping baked in, as Ex Machina does, so I can't comment on whether you need to rerip them or not.

Is it baked in? I haven't analysed the whole soundtrack yet, but speaking only about the beginning with the helicopter passing by (this is where the first potential clipping occurs, be it "baked in" or "generated while decoding"), it seems that the original source of unknown wordlength must have been halfway clipping-free.

By the way, when using the DTS core of Ex Machina, both decoders show the clipping. Almost philosophical question: is the clipping here part of the DTS file or is just no decoder able to reproduce it? ;)

I would guess it's probably rare. Maybe it's a side effect of DTS:X, maybe the encoder is not bug free yet, but I really don't know.

I understand. However, if I should find another piece without any Atmos or DTS:X - extensions, behaving the same way in regard to clipping (or not), then I guess we all should better start to know.

I think probably receivers would play Ex Machina clipped. But again I'm guessing, I've no idea.

I guess that demonstrates how academic this actually is. I mean even the slight clipping isn't really hearable (however the result with the buggy libdca was) and hardly any "normal user" will ever care what is really played back as long as the logo of the newest audio format lights up on his new AVR. :p

Lowering volume results in floating point values, which means dithering needs to be applied. This is *not* perfectly lossless, and the compression efficiency goes down dramatically. So lowering volume is not recommend, unless it's absolutely necessary.

Now I'm left wondering if the newest eac3to + libDca combo reconstructs the source of e.g. Ex Machina authentically or not. After all, it can't be lossless anymore after the volume change as you put it.

Let me sum this up: so we have a nominally lossless source format like DTS:X (maybe adding some effects in realtime, but let's stick to the 7.1 channels for now) and no real-life-decoder can actually reproduce the source which was used to create it. Instead of slight loss due to a psychoacoustic model, we have (maybe even slighter, but still) loss due to calculations, overhead and clipping. Awesome.

Yoshi

15th November 2015, 21:16

does it mean that the track or the conversion is not lossless after all in this case?

Sorry I can't resist: maybe we should have asked Kurt Gödel while he was still around. It might be lossless but we will never be able to prove it since the source is unknown and will be forever. ;)

I start to wonder how lossless my rips I thought they were, actually are.

Gives the same message for "Jurassic World" as well. Since I'm paranoid now, I let decode the same DTS-HD MA track twice to FLAC in one run (dcaDec & Arcsoft) and compare if the FLAC matches.

The FLACs match despite the XLL-warning. Really lossless? Well ...

Thunderbolt8

15th November 2015, 21:27

I edited my post and added another information.

Boulder

15th November 2015, 22:37

What I've noticed is that the XLL warning often kicks in right when the decoding starts.

Is the warning output only once or every time the decoder reports it? In the latter case, would it be possible to output also the timestamp?

Thunderbolt8

16th November 2015, 00:26

it might be the case that some intro or studio logo has a different bit depth than the rest of the movie. that could be one explanation.

LigH

16th November 2015, 09:10

Regarding DVD Video, that was one of the reasons to extract "the movie PGC" instead of processing VOB sequences as authored: to avoid trailer audio issues like asynchronity.

Removing trailers from BD playlists may be a different topic...

Thunderbolt8

17th November 2015, 06:51

are DTS:X headphone (2.0) tracks which are currently detected as DTS track by eac3to actually lossy or lossless tracks, like other DTS-HD MA tracks? and are DTS:X tracks are not denoted as such by eac3to yet?

Zenitram

17th November 2015, 08:04

DTS:X headphone (2.0) trac

Could you provide a sample file of DTS:X headphone?

ndjamena

17th November 2015, 10:43

If anyone is interested here's the latest unofficial MediaInfo dll:

http://www.mediafire.com/download/5y4o9xucw6eizhl/MediaInfo.zip

This is what it gets you:

General
Unique ID : 219291506723631580012532402152276823948 (0xA4FA02080541F5119808D773964D0F8C)
Complete name : D:\Zilla.mkv
Format : Matroska
Format version : Version 4 / Version 2
File size : 36.8 GiB
Duration : 2h 18mn
Overall bit rate mode : Variable
Overall bit rate : 37.9 Mbps
Movie name : Zilla
Encoded date : UTC 2015-11-17 09:05:56
Writing application : mkvmerge v8.5.1 ('Crosses') 64bit
Writing library : libebml v1.3.3 + libmatroska v1.4.4

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 2 frames
Format settings, GOP : M=1, N=10
Codec ID : V_MPEG4/ISO/AVC
Duration : 2h 18mn
Bit rate mode : Variable
Bit rate : 34.7 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.698
Stream size : 33.6 GiB (92%)
Language : English
Default : No
Forced : No

Audio
ID : 2
Format : FLAC
Format/Info : Free Lossless Audio Codec
Codec ID : A_FLAC
Duration : 2h 18mn
Bit rate mode : Variable
Bit rate : 3 202 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 24 bits
Detected bit depth : 20 bits
Stream size : 3.10 GiB (8%)
Writing library : libFLAC 1.2.1 (UTC 2007-09-17)
Language : English
Default : Yes
Forced : No

Text #1
ID : 3
Format : PGS
Muxing mode : zlib
Codec ID : S_HDMV/PGS
Codec ID/Info : Picture based subtitle format used on BDs/HD-DVDs
Duration : 2h 1mn
Bit rate : 11.4 Kbps
Count of elements : 2084
Stream size : 9.90 MiB (0%)
Language : English
Default : No
Forced : No

Text #2
ID : 4
Format : PGS
Muxing mode : zlib
Codec ID : S_HDMV/PGS
Codec ID/Info : Picture based subtitle format used on BDs/HD-DVDs
Duration : 1h 23mn
Bit rate : 198 bps
Count of elements : 36
Stream size : 121 KiB (0%)
Language : English
Default : No
Forced : No

Text #3
ID : 5
Format : PGS
Muxing mode : zlib
Codec ID : S_HDMV/PGS
Codec ID/Info : Picture based subtitle format used on BDs/HD-DVDs
Duration : 2h 9mn
Bit rate : 7 053 bps
Count of elements : 2460
Stream size : 6.52 MiB (0%)
Language : English
Default : No
Forced : No

Menu
00:00:00.000 : en:Start
00:07:48.092 : en:Collision Course
00:17:25.502 : en:Worm Guy
00:25:28.026 : en:"Gojira"
00:36:53.461 : en:Inside a Footprint
00:41:47.880 : en:Insurance Claim
00:48:19.479 : en:Caught on Something
01:01:35.900 : en:"I Got a Bite"
01:11:05.803 : en:New Kid in Town
01:21:38.685 : en:23Rd St. Station
01:30:26.087 : en:Drawing Him Out
01:39:13.989 : en:Fire at Will: One
01:50:23.867 : en:Copter Chase
01:52:28.658 : en:"He's Pregnant"
02:00:36.771 : en:Shaken, Not Stirred
02:05:56.882 : en:Section Five

Of note is "Detected bit depth" (EAC3To's "VALID_BITS" tag), channel layouts despite the fact that it's an EAC3To FLAC file without a WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag and all the tracks have bitrates, despite the fact that they're in an mkv and there are two variable bitrate tracks in there.

Subtitle track one has 2084 elements in it, subtitle two has only 36, that one must be forced subtitles, the last subtitle has 2460 elements, which is more than the first, so the first must be the regular subtitles and the last must be SDH.

Oh, right, the flac was muxed straight into the file using MKVMerge, so the UID is 3419832279421249968 and yet its statistics tags are still being applied to it correctly.

And then there's this:

General
Unique ID : 215636814642891718231343589359444197377 (0xA23A23CCC54ADBF1948103B2D1428001)
Complete name : D:\DTS-X.mka
Format : Matroska
Format version : Version 4 / Version 2
File size : 123 MiB
Duration : 3mn 32s
Overall bit rate : 4 861 Kbps
Encoded date : UTC 2015-11-15 15:35:39
Writing application : mkvmerge v8.5.1 ('Crosses') 64bit
Writing library : libebml v1.3.3 + libmatroska v1.4.4

Audio
ID : 1
Format : DTS
Format/Info : Digital Theater Systems
Format profile : X / MA / Core
Mode : 16
Format settings, Endianness : Big
Codec ID : A_DTS
Duration : 3mn 32s
Bit rate mode : Variable / Variable / Constant
Bit rate : 4 859 Kbps / 4 859 Kbps / 1 509 Kbps
Channel(s) : Object Orientated / 8 channels / 6 channels
Channel positions : Object Orientated / Front: L C R, Side: L R, Back: L R, LFE / Front: L C R, Side: L R, LFE
Sampling rate : / 48.0 KHz / 48.0 KHz
Bit depth : / 24 bits / 24 bits
Compression mode : / Lossless / Lossy
Stream size : 123 MiB (100%)
Language : English
Default : Yes
Forced : No

DTS:X

and this:

General
Unique ID : 186823894588399821734555224452256288412 (0x8C8CF929A176D63082E6B973CE30CE9C)
Complete name : D:\DTS ES.mka
Format : Matroska
Format version : Version 4 / Version 2
File size : 6.80 MiB
Duration : 4s 11ms
Overall bit rate : 14.2 Mbps
Encoded date : UTC 2015-11-13 23:30:23
Writing application : mkvmerge v8.5.1 ('Crosses') 64bit
Writing library : libebml v1.3.3 + libmatroska v1.4.4

Audio #1
ID : 1
Format : DTS
Format/Info : Digital Theater Systems
Format profile : MA / ES Matrix / Core
Mode : 16
Format settings, Endianness : Big
Codec ID : A_DTS
Duration : 4s 10ms
Bit rate mode : Variable / Constant / Constant
Bit rate : 2 812 Kbps / 1 509 Kbps / 1 509 Kbps
Channel(s) : 8 channels / 7 channels / 6 channels
Channel positions : Front: L C R, Side: L R, Back: L R, LFE / Front: L C R, Side: L R, Back: C, LFE / Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 24 bits
Compression mode : Lossless / Lossy / Lossy
Stream size : 1.34 MiB (20%)
Language : English
Default : Yes
Forced : No

Audio #2
ID : 2
Format : DTS
Format/Info : Digital Theater Systems
Format profile : MA / ES Discrete / Core
Mode : 16
Format settings, Endianness : Big
Codec ID : A_DTS
Duration : 4s 0ms
Bit rate mode : Variable / Constant / Constant
Bit rate : 2 269 Kbps / 1 509 Kbps / 1 509 Kbps
Channel(s) : 7 channels / 7 channels / 6 channels
Channel positions : Front: L C R, Side: L R, Back: C, LFE / Front: L C R, Side: L R, Back: C, LFE / Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 24 bits
Compression mode : Lossless / Lossy / Lossy
Stream size : 1.08 MiB (16%)
Language : English
Default : No
Forced : No

Audio #3
ID : 3
Format : DTS
Format/Info : Digital Theater Systems
Format profile : ES Discrete / Core
Mode : 16
Format settings, Endianness : Big
Codec ID : A_DTS
Duration : 4s 0ms
Bit rate mode : Constant
Bit rate : 1 509 Kbps
Channel(s) : 7 channels / 6 channels
Channel positions : Front: L C R, Side: L R, Back: C, LFE / Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 24 bits
Compression mode : Lossy
Stream size : 737 KiB (11%)
Language : English
Default : No
Forced : No

DTS ES in all it's glory.

Frechdachs

19th November 2015, 07:23

I have a question regarding a 2.0 24-bit DTS-HD MA file. I've decoded it with dcadec (eac3to v3.31) and the Arcsoft decoder (eac3to v3.28) and the file decoded with the Arcsoft decoder is quieter.

According to eac3to the DTS file has a Dialnorm value of -4dB. If my assumptions about Dialnorm are correct, that means that a gain has to be applied, since neither flac nor wav support Dialnorm. I thought that maybe the dialogue normalization wasn't taken into account while using the Arcsoft decoder, so I encoded it again with the "+4dB" option and tested the difference to the dcadec version. In order to do so I opened both audio streams in Reaper and aplied phase inversion to one of the streams. Now if they are identical they should cancel each other out resulting in complete silence. There was still a sound at about -120dB (deviation from the peak), which is absolutely inaudible, though.

Since I don't know much about Dialnorm I want to ask which version is correct, the one without the gain or the one with it and the dcadec version.
Also, is there a reason there is still a small measurable difference between the Arcsoft decoded file with the gain and the one decoded by dcadec, shouldn't they be the same if the gain is applied manually?
And finally, is there a better way to check if two audio files are identical?

On a side note, I did the same test with Reaper using a 5.1 24-bit DTS-HD MA track without a Dialnorm value. There was no measurable difference between Arcsoft and dcadec, meaning they are in fact completely identical.

tebasuna51

19th November 2015, 11:02

@Frechdachs

- Dialog Normalization was a interesting concept if all sounds respect it.
But there are many (TV advertisement, remastered CD's Loudness war (https://en.wikipedia.org/wiki/Loudness_war), ...) than try to offer the max digital volume in the wrong concept than loud volume is better quality. Thats enforce to use the Volume knob between normalized and not normalized sounds.
eac3to is a transcoding tool and, by default, try, if can do, to not apply Dialog Normalization to offer the original sound without attenuation.
What is correct? Is your choice.

- There are other methods to compare wav's but for this pourpose your method is correct (I also use it).
Take in mind than apply -4dB gain (DialNorm), and after a manual +4dB gain, is not a lossless operation and your can lose a bit of precission.
The dcadec output is the lossless source.

airsoft

19th November 2015, 14:57

And finally, is there a better way to check if two audio files are identical?

E:\>md5sum Tomorrowland*.wav
8e8d58cc32c6432a0c5222c7086e6444 *Tomorrowland_ArcSoft_decoder_eac3to-3.31.wav
8e8d58cc32c6432a0c5222c7086e6444 *Tomorrowland_default_eac3to-3.31.wav

listing of cmd prompt command dir - filesize and name

8 989 397 060 Tomorrowland_ArcSoft_decoder_eac3to-3.31.wav
8 989 397 060 Tomorrowland_default_eac3to-3.31.wav

I hope it was helpful for you as technique. Seems both "libDcaDec" and "ArcSoft" produces identical files which means according my knowledge the original lossless audio

AlexKane

19th November 2015, 17:18

@Frechdachs

Assuming you want the best possible result (sorry), the correct "version" is the one produced by dcadec, since it does not apply 4db of gain reduction. As tebasuna51 mentioned, the Arcsoft file will be lower quality since the LSBs (the noisefloor @ 120db) get trashed as your source file is integer precision format.

Megalith

19th November 2015, 21:15

Is eac3to still unable to remove dialnorm from DTS-HD MA tracks?

SeeMoreDigital

19th November 2015, 21:52

Is eac3to still unable to remove dialnorm from DTS-HD MA tracks?Come to think of it. I don't think I've ever seen my surround sound amplifier respond to a DTS-HD MA dialnorm flag. I've only ever seen it respond to a Dolby Digital dialnorm flag :eek:

madshi

19th November 2015, 22:06

The Dolby Digital spec requires Dolby Digital decoders to apply dialnorm by default, unless the user specifically disables it. DTS is not as stupid, fortunately, so DTS tracks have much less problems with that. When using libdcadec, dialnorm is by default ignored, so eac3to decoding no longer has any problems with that, anyway. eac3to still cannot fully remove dialnorm from DTS-HD tracks, though, because doing so would require to rewrite the whole HD frame structure, including CRCs etc, which is very complicated.

Thunderbolt8

19th November 2015, 22:48

does detecting DTS:X headphone tracks work differently from detecting norma DTS:X tracks? from what Ive heard using this info here https://github.com/foo86/dcadec/issues/37 does not lead to success in cases of headphone tracks.

maybe the dcadec developer could be able to figure something out as well in this case?

Frechdachs

19th November 2015, 23:19

- Dialog Normalization was a interesting concept if all sounds respect it.
But there are many (TV advertisement, remastered CD's Loudness war (https://en.wikipedia.org/wiki/Loudness_war), ...) than try to offer the max digital volume in the wrong concept than loud volume is better quality.

But why is it used on Blu-rays? There are no advertisments interrupting the movie, so there should be no need to constantly have to adjust the volume.

The Dolby Digital spec requires Dolby Digital decoders to apply dialnorm by default, unless the user specifically disables it. DTS is not as stupid, fortunately, so DTS tracks have much less problems with that. When using libdcadec, dialnorm is by default ignored, so eac3to decoding no longer has any problems with that, anyway.

That means I am misinterpreting dialnorm afterall. I thought that a dialnorm of -4dB would mean that in order to honor dialnorm a positive gain of 4dB has to be applied after decoding. But since you wrote that dialnorm is ignored for DTS-HD while using dcadec and not while using Arcsoft, there is rather a negative gain applied if dialnorm is honored (because in my test using dcadec resulted in a file that was 4dB louder than Arcsoft).

So if I get it straight this time, it meanst that when I use the Arcsoft decoder with the "+4dB" option, there is first a negative gain of -4dB applied (because of dialnorm) and then a positive gain again, which is retarded.

Is this correct?

eac3to still cannot fully remove dialnorm from DTS-HD tracks, though, because doing so would require to rewrite the whole HD frame structure, including CRCs etc, which is very complicated.

You mean when input and output is both DTS? If encoding to flac for example, either dialnorm has to be ignored or there has to be a gain applied, because flac doesn't support dialnorm. Or does it?

nevcairiel

19th November 2015, 23:24

You mean when input and output is both DTS? If encoding to flac for example, either dialnorm has to be ignored or there has to be a gain applied, because flac doesn't support dialnorm. Or does it?

When eac3to decodes the DTS track to convert it to FLAC, dialnorm is simply ignored.

AlexKane

20th November 2015, 08:41

That means I am misinterpreting dialnorm afterall. I thought that a dialnorm of -4dB would mean that in order to honor dialnorm a positive gain of 4dB has to be applied after decoding.

You indeed misinterpret dialnorm, as it is the exact opposite of what you thought.
A dialnorm flag of -4db means that the decoder needs to apply 4db of gain reduction during decoding. In your case, Arcsoft respects the dialnorm flag while dcadec does not.
If all you want is "Extract the audio as it is stored" and encode it in another format, you need to use dcadec. You can then apply any level adjustment during playback.

tebasuna51

20th November 2015, 09:30

...
So if I get it straight this time, it meanst that when I use the Arcsoft decoder with the "+4dB" option, there is first a negative gain of -4dB applied (because of dialnorm) and then a positive gain again, which is retarded.

Is this correct?
Yes Arcsoft apply -4dB (dialnorm) and after eac3to apply +4dB.
But not retarded, when you recode the time to do the operations is not important. Is other problem:

You lose precission in round to int values.

For instance you have a sample with a int 24 bits volume value of 16777211.
When you apply -4dB you obtain a real value than you must round to int:

Int value -4dB Int Up Int Down
--------- ------------- -------- --------
16777211 10585704,5003 10585705 10585704

But round up or down whe you apply +4dB:

Int value +4dB Int
--------- ------------- --------
10585705 16777211,7919 16777212
10585704 16777210,2070 16777210

You never finish with the lossless value 16777211

Frechdachs

20th November 2015, 21:58

Thank you for all the replys. Everything makes sense now.

You indeed misinterpret dialnorm, as it is the exact opposite of what you thought.

Yeah, I was probably misguided by the fact that the DTS track isn't very loud to begin with. It's a bit odd that the studio would want to reduce the volume even further during playback.

You lose precission in round to int values.
[...]
You never finish with the lossless value 16777211

That's what I meant when I said that it would be kind of stupid by me to do that. But thanks for the explaination on how the precision loss comes to be. Much appreciated.

ndjamena

21st November 2015, 00:16

https://github.com/MediaArea/MediaInfoLib/commit/5d3f12867ab1ee06c22148ac8f4d5b9e34f94144

if (HD_SubStreams_Count == 4) Fill(Stream_Audio, 0, Audio_Codec, "ATMOS");

Is EAC3To's detection of ATMOS any more complicated than that?

Is there anything else I should look out for?

kukushka

21st November 2015, 16:56

eac3to + Nero Audio Decoder (Nero 7) are dropping first aac frame on decoding. always. along with faad. ffmpeg & Nero AAC Decoder 1.5.1.0 are doing it correctly. can be verified as example with extracted aac from qaac --no-delay encoding
possible solution - to feed first frame twice to decoder?
oh, and as i've heard, 5.1 aac decoding is broken in eac3to after 3.0.1 version, but it's probably nothing new with it
/just sayin'

Music Fan

21st November 2015, 20:46

eac3to + Nero Audio Decoder (Nero 7) are dropping first aac frame on decoding. always. along with faad. ffmpeg & Nero AAC Decoder 1.5.1.0 are doing it correctly.
Did you also try neroAacDec alone to see if the first aac frame is dropped ?

tebasuna51

21st November 2015, 21:45

eac3to + Nero Audio Decoder (Nero 7) are dropping first aac frame on decoding. always. along with faad. ffmpeg & Nero AAC Decoder 1.5.1.0 are doing it correctly.

I agree with the Nero 7 behaviour but not with faad (14/06/2010 from RareWares) and even with NeroAacDec 1.5.1.0.

Encode/Decoder Nero7 NeroDec Faad Qaac ffmpeg
--------------- ------ ------- ---- ---- ------
2.0-nero.m4a - Ok +33 Ok Ok
5.1-nero.m4a - Ok +33 Ok Ok
2.0-qaac.aac +22 - +22 +44 +44
2.0-qaac.m4a - Ok +22 Ok Ok
5.1-qaac.aac broken - +22 +44 +44
5.1-qaac.m4a - Ok +22 Ok Ok
2.0-qaac-ND.aac -21 - -21 Ok Ok
2.0-qaac-ND.m4a - 0 -21 Ok Ok
5.1-qaac-ND.aac broken - -21 Ok Ok
5.1-qaac-ND.m4a - 0 -21 Ok Ok

ND = qaac --no-delay parameter
-21 = first frame cutted
+x = ms of silence delay added
0 = first frame silenced
- = Not supported

kukushka

21st November 2015, 22:33

Did you also try neroAacDec alone to see if the first aac frame is dropped ?
"Nero AAC Decoder 1.5.1.0" - this is neroAacDec and it's all good with it.

I agree with the Nero 7 behaviour but not with faad (14/06/2010 from RareWares) and even with NeroAacDec 1.5.1.0.

the thing with faad is that it is broken even more, not only it drops the first frame, it also ignores initial m4a header that tells other decoders (that can work with m4a directly obviously) what to skip. and no silence is added by decoders (qaac --no-delay shows it clearly), it is coded in aac and then skipped or decoded with or without frame drop depending on container/decoder

tests are for 2.0

process-decoder\coder nero qaac default qaac --no-delay
samples ms samples ms samples ms
m4a-faad 1600 33,33 1088 22,67 -1024 -21,33
m4a-ffmpeg 0 0 0 0 0 0
aac-eac3to&faad 1600 33,33 1088 22,67 -1024 -21,33
aac-ffmpeg 2624 54,67 2112 44 0 0
aac-mp4-faad 1600 33,33 1088 22,67 -1024 -21,33
aac-mp4-ffmpeg 2624 54,67 2112 44 0 0
aac-mkv-eac3to 1600 33,33 1088 22,67 -1024 -21,33
aac-mkv-ffmpeg 2624 54,67 2112 44 0 0
mkv w delay-eac3to -1040 -21,67 -1024 -21,33
mkv w delay-ffmpeg -448 -9,333 -960 -20
mkv-eac3to -1472 -30,67 -1984 -41,33 -1024 -21,33
mkv-ffmpeg -448 -9,333 -960 -20 0 0
ts-eac3to 1600 33,33 1088 22,67 -1024 -21,33
ts-ffmpeg 2624 54,67 2112 44 0 0

i omitted some identical results (like neroaacdec behavior = ffmpeg), they're mentioned in conclusions
m4a - initial encode
aac - demux from m4a with mp4muxer
aac-mp4 - remuxed back with mp4muxer, initial headers got stripped
aac-mkv - mkvtoolnix 8.5.2 was used
mkv w delay - m4a to mkv with additional track - container delays, 20ms for default qaac, 9ms for nero
ts - muxed from m4a with tsmuxer 1.10.6
versions:
eac3to 3.30, nerodec 1.5.1.0, neroenc 1.5.4.0, qaac 2.55-7.10.5.0, ffmpeg N-76417-gee20354, faad 373248B
conclusions:
encoders: nero - 2624 samples initial delay, qaac - 2112 by default
faad don't give a damn about m4a header
faad & eac3to both kill first frame (1024samples)
nero & ffmpeg (and foobar) -ok in m4a
mkv muxing from m4a tries to compensate coder delays by killing a few frames. and then adding a delay. or not adding when it's a single track which leads to -960 samples with qaac when properly decoded or almost 2k with nero7 frame drop
foobar is using ffmpeg engine so results are identical
ffmpeg (with foobar) don't count mkv delays
neroaacdec & ffmpeg results are identical too

tebasuna51

22nd November 2015, 03:42

Overdrive80

22nd November 2015, 12:38

Hi, folks. I purchase bluray and get this errors with eac3to:

M2TS, 1 video track, 5 audio tracks, 6 subtitle tracks, 1:49:25, 28.878p
1: Chapters, 12 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: DTS Master Audio, Spanish, 5.1 channels, 16 bits, 48kHz
(core: DTS, 5.1 channels, 768kbps, 48kHz)
4: DTS Master Audio, Spanish, 5.1 channels, 16 bits, 48kHz
(core: DTS, 5.1 channels, 768kbps, 48kHz)
5: DTS Master Audio, Spanish, 5.1 channels, 16 bits, 48kHz
(core: DTS, 5.1 channels, 768kbps, 48kHz)
6: DTS Master Audio, Spanish, 5.1 channels, 16 bits, 48kHz
(core: DTS, 5.1 channels, 768kbps, 48kHz)
7: DTS Master Audio, Spanish, 5.1 channels, 16 bits, 48kHz
(core: DTS, 5.1 channels, 768kbps, 48kHz)
8: Subtitle (PGS)
9: Subtitle (PGS)
10: Subtitle (PGS)
11: Subtitle (PGS)
12: Subtitle (PGS)
13: Subtitle (PGS)
[a03] Extracting audio track number 3...
[a03] Decoding with libDcaDec DTS Decoder...
[a03] libDcaDec reported the warning "XLL output not lossless". <WARNING>
[a03] Writing WAV...
[a03] Creating file "E:\Bluray\DBZ BOG EXTENDED\_3spa.wav"...
[a03] Skipping identical DTS frames (seamless branching)...
[a03] libDcaDec output changed from 6 channels, 48kHz to 2 channels, 48kHz. <ERROR>
Aborted at file position 21188608. <ERROR>

I attempt decoding using Arcsoft but issue report is the same.

Command line: "eac3to.exe" "E:\Bluray\DBZ BOG EXTENDED\" 1) 3: "E:\Bluray\DBZ BOG EXTENDED\_3spa.wav" -progressnumbers

EDIT: If I use m2ts directly on eac3to, work fine. I think that is one problem of playlist.

EDIT2: I ever get audio 2 channels with mt2s, but not 5.1.

Thunderbolt8

22nd November 2015, 13:57

Overdrive80

22nd November 2015, 14:23

did you check the playlist file of how many .m2ts files it consists (the file itself, not what eac3to displays)? perhaps the main .m2ts file is preceeded by some other small .m2ts file which has a 5.1 channel configuration.

Yes, its composed of two m2ts (0003.mt2s+0000.m2ts), however 0003.m2ts is short video of presentation of distribution company, nothing of interest.

I can extract audio track in dtshd (1,3 gb), but is impossible transcoding, ever get error.

Thunderbolt8

22nd November 2015, 15:13

then just skip that one and only work with the main movie file.

Overdrive80

22nd November 2015, 15:29

then just skip that one and only work with the main movie file.

The problem is that main movie info 2 channels from m2ts, but dtshd extracted info 6 channels, and I can not decoding audio:

General
Nombre completo : E:\Bluray\DBZ BOG EXTENDED\00000.mpls_3spa.dtshd
Formato : DTS
Formato/Info : Digital Theater Systems
Formato del perfil : MA / Core
Tamaño del archivo : 1,23GIB
Modo de tasa de bits : Variable

Audio
Formato : DTS
Formato/Info : Digital Theater Systems
Formato del perfil : MA / Core
Format_Settings_Mode : 16
Ajustes del formato, Endianness : Big
Tipo de tasa de bits : Variable
Tasa de bits : Desconocido / 768Kbps
Canal(es) : 6canales
Posiciones del canal : Front: L C R, Side: L R, LFE
Velocidad de muestreo : 48,0KHz
BitDepth/String : 16bits
Compression_Mode/String : / Lossy

From m2ts:

General
ID : 0 (0x0)
Nombre completo : E:\Bluray\DBZ BOG EXTENDED\BDMV\STREAM\00000.m2ts
Formato : BDAV
Formato/Info : Blu-ray Video
Tamaño del archivo : 21,8GIB
Duración : 1h 49min.
Modo de tasa de bits : Variable
Tasa de bits total : 28,6Mbps
Tasa de bits máxima : 48,0Mbps

Video
ID : 4113 (0x1011)
ID Menú : 1 (0x1)
Formato : AVC
Formato/Info : Advanced Video Codec
Formato del perfil : High@L4.1
Ajustes del formato, CABAC : Si
Ajustes del formato, RefFrames : 4marcos
ID Códec : 27
Duración : 1h 49min.
Tipo de tasa de bits : Variable
Tasa de bits máxima : 35,0Mbps
Ancho : 1 920pixeles
Alto : 1 080pixeles
Relación de aspecto : 16:9
Velocidad de cuadro : 23,976fps
Estándar : NTSC
ColorSpace : YUV
ChromaSubsampling : 4:2:0
BitDepth/String : 8bits
Tipo de exploración : Progresivo
colour_range : Limited
colour_primaries : BT.709
transfer_characteristics : BT.709
matrix_coefficients : BT.709

Audio #1
ID : 4352 (0x1100)
ID Menú : 1 (0x1)
Formato : DTS
Formato/Info : Digital Theater Systems
Formato del perfil : MA / Core
Format_Settings_Mode : 16
Ajustes del formato, Endianness : Big
Modo Muxing : Stream extension
ID Códec : 134
Duración : 1h 49min.
Tipo de tasa de bits : Variable
Tasa de bits : Desconocido / 1 509Kbps
Canal(es) : 2canales
Posiciones del canal : Front: L R
Velocidad de muestreo : 48,0KHz
BitDepth/String : 16bits
Compression_Mode/String : / Lossy

SeeMoreDigital

22nd November 2015, 15:34

Over the last few months I've been backing-up all my multi-channel (DVD-A, Blu-Ray Audio and DTS-CD) albums to single multi-channel flac files complete with a cue file.

All had been going very well up-until this morning, when I tried to back-up my 'Don Henley - End Of The Innocence' DTS-CD. After some investigation I've determined that the problem lies with the disc's very first track, which has been encoded using 6.1 DTS-ES audio, instead of regular 5.1 DTS audio.

So far I've managed to back-up the first track to a (52.6MB) dts-es.wav file. And I've also managed to extract the elementary (46.0MB) dts-es.dts stream - but now I'm stumped :eek:

Ideally what I'd like to do is create a 5.1 channel flac file from the 6.1 channel dts-es source but sadly neither LameXP or UsEac3to (with eac3to v3.31) are able to do this.

Does anyone have any ideas?

EDIT: Here's a link to a 5 second DTS-ES sample (https://www.sendspace.com/file/lj6nys)

Thunderbolt8

22nd November 2015, 16:21

The problem is that main movie info 2 channels from m2ts, but dtshd extracted info 6 channels, and I can not decoding audio:

General
Nombre completo : E:\Bluray\DBZ BOG EXTENDED\00000.mpls_3spa.dtshd
Formato : DTS
Formato/Info : Digital Theater Systems
Formato del perfil : MA / Core
Tamaño del archivo : 1,23GIB
Modo de tasa de bits : Variable

Audio
Formato : DTS
Formato/Info : Digital Theater Systems
Formato del perfil : MA / Core
Format_Settings_Mode : 16
Ajustes del formato, Endianness : Big
Tipo de tasa de bits : Variable
Tasa de bits : Desconocido / 768Kbps
Canal(es) : 6canales
Posiciones del canal : Front: L C R, Side: L R, LFE
Velocidad de muestreo : 48,0KHz
BitDepth/String : 16bits
Compression_Mode/String : / Lossy

From m2ts:

General
ID : 0 (0x0)
Nombre completo : E:\Bluray\DBZ BOG EXTENDED\BDMV\STREAM\00000.m2ts
Formato : BDAV
Formato/Info : Blu-ray Video
Tamaño del archivo : 21,8GIB
Duración : 1h 49min.
Modo de tasa de bits : Variable
Tasa de bits total : 28,6Mbps
Tasa de bits máxima : 48,0Mbps

Video
ID : 4113 (0x1011)
ID Menú : 1 (0x1)
Formato : AVC
Formato/Info : Advanced Video Codec
Formato del perfil : High@L4.1
Ajustes del formato, CABAC : Si
Ajustes del formato, RefFrames : 4marcos
ID Códec : 27
Duración : 1h 49min.
Tipo de tasa de bits : Variable
Tasa de bits máxima : 35,0Mbps
Ancho : 1 920pixeles
Alto : 1 080pixeles
Relación de aspecto : 16:9
Velocidad de cuadro : 23,976fps
Estándar : NTSC
ColorSpace : YUV
ChromaSubsampling : 4:2:0
BitDepth/String : 8bits
Tipo de exploración : Progresivo
colour_range : Limited
colour_primaries : BT.709
transfer_characteristics : BT.709
matrix_coefficients : BT.709

Audio #1
ID : 4352 (0x1100)
ID Menú : 1 (0x1)
Formato : DTS
Formato/Info : Digital Theater Systems
Formato del perfil : MA / Core
Format_Settings_Mode : 16
Ajustes del formato, Endianness : Big
Modo Muxing : Stream extension
ID Códec : 134
Duración : 1h 49min.
Tipo de tasa de bits : Variable
Tasa de bits : Desconocido / 1 509Kbps
Canal(es) : 2canales
Posiciones del canal : Front: L R
Velocidad de muestreo : 48,0KHz
BitDepth/String : 16bits
Compression_Mode/String : / Lossydid you really use the 00000.m2ts file to extract the audio from and not the .mpls file? because according to the file name of your .dtshd track this is at least what is indicated here.

Overdrive80

22nd November 2015, 16:57

Yes, I used playlist and mt2s. From playlist can only extract dts files, with m2ts can extract and transcoding but I never get audio 5.1 only 2.0. Is posible that this company had hack playlist for showing false dts 5.1?

ndjamena

22nd November 2015, 17:23

Where is it showing false information?

The first m3ts contains 5.1 audio, the second 2.0. If you extract the playlist the header at the beginning will come from the first file and show as 5.1. If you only extract from the second m2ts it will always show as 2.0, because that is what is in the file.

There is no 5.1 to decode, unless you like the intro in the first m2ts enough that you'd like to keep it.

Your options are to ditch the intro, or downmix the sound from it to stereo and prepend it to the audio from the second m2ts file.

Overdrive80

22nd November 2015, 17:45

And can not it done intentionally?? Company sold product like DTS-MA 5.1: http://www.amazon.es/Dragon-Battle-Edic-Coleccionista-Blu-ray/dp/B00VVQD7YI/ref=pd_sim_74_6?ie=UTF8&dpID=6127ukb533L&dpSrc=sims&preST=_AC_UL160_SR158%2C160_&refRID=1A7QSJVR19TT8QQ27FWS (Pre-sold that I got)

I am refering to false info to:
http://s7.postimg.org/o739b1dg7/Captura_de_pantalla_2015_11_22_17_40_16.jpg (http://postimg.org/image/o739b1dg7/)

Thunderbolt8

22nd November 2015, 18:37

in that case you could try to contact the company and tell them about it & complain, get a refund etc.

tebasuna51

22nd November 2015, 20:12

Ideally what I'd like to do is create a 5.1 channel flac file from the 6.1 channel dts-es source but sadly neither LameXP or UsEac3to (with eac3to v3.31) are able to do this.

Without problem here using your sample and:

%_.flac -down6

eac3to v3.31
command line: "D:\Programa\eac3to\eac3to.exe" "D:\tmp\5 sec DTS-ES elementary stream sample.dts" "D:\tmp\5 sec DTS-ES elementary stream sample.dts_.flac" -down6 -progressnumbers -log="D:\Programa\eac3to\UsEac3to\UsEac3To.log"
------------------------------------------------------------------------------
DTS-ES, 6.1 channels, 0:00:05, 1235kbps, 44.1kHz
Decoding with libDcaDec DTS Decoder...
Mixing surround channels...
Encoding FLAC with libFlac...
Creating file "D:\tmp\5 sec DTS-ES elementary stream sample.dts_.flac"...
eac3to processing took 1 second.
Done.

FLAC, 5.1 channels, 0:00:05, 24 bits, 3530kbps, 44.1kHz
Also ok to wav. I don't know how you obtain your "5 sec DTS-ES in WAV sample.wav"
WAV, 2.0 channels, 0:00:05, 16 bits, 1411kbps, 44.1kHz

SeeMoreDigital

22nd November 2015, 20:50

Without problem here using your sample and:
%_.flac -down6

I actually tried these command line parameters with UsEac3To but I get this warning: -

eac3to v3.31
command line: "C:\UsEac3to118\eac3to.exe" "C:\Users\SeeMoreDigital\Desktop\The End of the Innocence.dts" "C:\Users\SeeMoreDigital\Desktop\The End of the Innocence.dts_.flac" -down6 -progressnumbers -log="C:\UsEac3to118\UsEac3To.log"
------------------------------------------------------------------------------
DTS-ES, 6.1 channels, 0:05:13, 1235kbps, 44.1kHz
Decoding with libDcaDec DTS Decoder...
Mixing surround channels...
Encoding FLAC with libFlac...
Creating file "C:\Users\SeeMoreDigital\Desktop\The End of the Innocence.dts_.flac"...
libDcaDec reported the warning "Failed to parse core extension". <WARNING>
libDcaDec output changed from 7 channels, 44kHz to 6 channels, 44kHz. <ERROR>
Aborted at file position 1310720. <ERROR>

Cheers

tebasuna51

22nd November 2015, 22:57

libDcaDec output changed from 7 channels, 44kHz to 6 channels, 44kHz. <ERROR>
Aborted at file position 1310720. <ERROR>
Yep, seems the problem you say: "the problem lies with the disc's very first track, which has been encoded using 6.1 DTS-ES audio, instead of regular 5.1"

Then you need split your dts in 2 parts, only the first one need the -down6

eac3to 1.dts 1.wav -down6
eac3to 2.dts 2.wav

After you can concatenate the 2 wav's:

sox 1.wav 2.wav full.wav

And encode to flac:

eac3to full.wav full.flac

The problem now is split the dts. Like "Aborted at file position 1310720", maybe you can upload me 2MB and I can say you how split the dts:

eac3to full.dts begin.dts -2mb

SeeMoreDigital

22nd November 2015, 23:24

Yep, seems the problem you say: "the problem lies with the disc's very first track, which has been encoded using 6.1 DTS-ES audio, instead of regular 5.1"

maybe you can upload me 2MB and I can say you how split the dts...

Many thanks for looking into this. You're right the 5 second sample encodes fine but I've just cut off a 10 second sample which does not.

Here's a link to a 10 second DTS-ES sample (https://www.sendspace.com/file/vvxuft). And another to the full dts-es file (https://www.sendspace.com/file/c5hmpz).

Cheers

tebasuna51

23rd November 2015, 02:08

@SeeMoreDigital

Is not so easy, the dts is corrupt and there are 37 frames along the full dts (13460 frames) with the BC channel unrecoverable.

eac3to crash decoding with dcadec and Arcsoft. With libav produce 346 WARNINGS and the decoded wav is useless.

I have succes with BeHappy decoding the dts to wav 6.1 with:
LWLibavAudioSource("D:\tmp\input.dts", stream_index=0,cache=false)
than use dcadec also. Here I see the 37 broken frames decoded as silence.

Using Foobar2000 I get a wav 5.1 with the BC channel already mixed in BL-BR. Sound fine for me: https://www.sendspace.com/file/lw3fl1

SeeMoreDigital

23rd November 2015, 10:32

@SeeMoreDigital

Is not so easy, the dts is corrupt and there are 37 frames along the full dts (13460 frames) with the BC channel unrecoverable.

Thank-you so much for doing this.

So the actual dts-es elementary stream is at fault. Do you think this could this have happened when it was extracted from the .wav container using DTSParser v2. Or somewhere else?

Thanks again :)

tebasuna51

23rd November 2015, 12:42

Do you think this could this have happened when it was extracted from the .wav container using DTSParser v2. Or somewhere else?

The dts play fine when I send it by spdif to my 5.1 receiver, maybe with a 6.1 or 7.1 we can listen some clicks in back speakers, but downmixed to 5.1 I can't listen anything strange.

Maybe the original DTS was wrong encoded or the original CD was dirty when ripped to wav, I don't think than the DTSParser was the culprit.
Try to clean the CD and rerip the track.

SeeMoreDigital

25th November 2015, 17:10

Maybe the original DTS was wrong encoded or the original CD was dirty when ripped to wav, I don't think than the DTSParser was the culprit.
Try to clean the CD and rerip the track.Update: I've cleaned the disc. And used several CD ripping applications, including EAC. But it would seem that the actual data for that particular track is corrupt in some way.

As a side note. Here's an interesting thing. If you encode the dts.wav file to flac. And then the flac file back to wav. The dts stream is still completely intact...

Cheers

Soulvomit

3rd December 2015, 09:03

I wanted to get an 11:08.192 clip from a 1:52:59.136 AC3 from the 1:39:36.770 mark and after much trial and error I stumbled upon the combination of "-edit=1:50:44.939,-5976770ms" and "-5976770ms" to do so. With "-edit=1:50:44.939,-5976770ms" alone, the AC3 would decode up to 1:50:44.939. With "-5976770ms" alone, it would do so from 1:39:36.770 to the end, 1:52:59.136. Now is there a particular reason why trimming a track requires two options, in different formats no less?eac3to %%a.ac3 %%~na.wav -edit=1:50:44.939,-5976770ms -5976770ms -full -no2ndpass Why isn't such a pedestrian task simple and intuitive? Can a better, more uniform option for this be implemented, preferably in milliseconds, or better yet, samples? Something like:-ms-in=5976770 -ms-out=6644939 or -sample-in=286884998 -sample-out=318957039

ndjamena

3rd December 2015, 09:30

Update: I've cleaned the disc. And used several CD ripping applications, including EAC. But it would seem that the actual data for that particular track is corrupt in some way.

As a side note. Here's an interesting thing. If you encode the dts.wav file to flac. And then the flac file back to wav. The dts stream is still completely intact...

Cheers

What was the bit rate of the FLAC?

SeeMoreDigital

3rd December 2015, 16:32

What was the bit rate of the FLAC?
1,260Kbps (using compression level 6)...

Thunderbolt8

7th December 2015, 19:27

Madshi, could you please update dcadec in eac3to? The XXL not lossless warning seems to have been removed and as of November 27th it has reached version 0.1

nevcairiel

7th December 2015, 20:10

Madshi, could you please update dcadec in eac3to? The XXL not lossless warning seems to have been removed and as of November 27th it has reached version 0.1

The warning going away is just cosmetic though, so don't worry too much about it.

madshi

7th December 2015, 20:19

Furthermore you can just compile a new libdcadec.dll yourself and use it with eac3to. I'm not using any patches, so any newer version than the one I'm using should work fine.

airsoft

7th December 2015, 20:54

As we talk about DTS what about DTS:X support, at least a detection

Sent from my HTC Desire 516 dual sim using Tapatalk

Thunderbolt8

8th December 2015, 18:46

Furthermore you can just compile a new libdcadec.dll yourself and use it with eac3to. I'm not using any patches, so any newer version than the one I'm using should work fine.does it matter whether I compile and use the x64 or win32 one?

Boulder

8th December 2015, 18:59

Eac3to is a 32-bit application so it can only call x86 libraries.

Thunderbolt8

9th December 2015, 23:51

compared to a HDD, would running eac3to with 2 SSDs in raid mode 0 speed up remuxing blu-rays quite a lot? (reading and writing from the disk)

heerschop

11th December 2015, 14:18

Furthermore you can just compile a new libdcadec.dll yourself and use it with eac3to. I'm not using any patches, so any newer version than the one I'm using should work fine.

I now this is a bit of topic but I am trying to build the libdcadec.dll with visual studio 2015.
I succeeded in building the libdcadec.dll but the .dll is painfully slow in decoding my dts steams.
The libdcadec.dll that came with eac3to took about 2 minutes to decode the dts.
With my own build it took about 9 minutes to decode the same dts.
Are there any options in visual studio to set that influence the performance of the created libdcadec.dll?

Groucho2004

11th December 2015, 14:29

Are there any options in visual studio to set that influence the performance of the created libdcadec.dll?
Did you build a debug or a release DLL?

heerschop

11th December 2015, 14:57

Did you build a debug or a release DLL?

I did build a release dll.

Groucho2004

11th December 2015, 16:38

I did build a release dll.
In that case - no idea why it's so much slower. Try building it with GCC.

Q-the-STORM

12th December 2015, 06:33

madshi, do you have any intention of including speedup/slowdown functionality for chapters? As far as I can see there are no chapter programs that let you speedup via CLI, so speeding up multiple files is a big hassle... since it is just a simple calculation, it should not be that hard to implement (I guess)... though I know chapter editing is not really eac3to's purpose, so I get it if you don't implement it...

on another matter, I'm gonna dig up a question I asked almost 2 years ago:
Are you going to replace libaften with libav for ac3 encoding in the foreseeable future? last time I asked, you said you haven't gotten around to it... since libav is the best choice for ac3 encoding (apart from the official dolby pro encoder, which I guess can't be implemented in eac3to :P) it would be nice to have it directly in eac3to and not have to pipe it to ffmpeg every time...

tebasuna51

12th December 2015, 12:31

madshi, do you have any intention of including speedup/slowdown functionality for chapters?

By the moment you can try the GUI UsEac3to:

- Load the .txt (Chapters OGM) or .xml chapters in UsEac3to.
Also text subs .srt, .ssa or .ass are supported.

- Ignore the eac3to message:
"The format of the source file could not be detected. <ERROR>"

- Click in the 'Auxiliary tools' -> 'SRT/.../TXT'

- Select your desired conversion and 'Convert'

Q-the-STORM

12th December 2015, 13:08

By the moment you can try the GUI UsEac3to:

this seems to work for single files only... There are already a few programs out there that do that, I need it to convert multiple files at once, which is only possible if the either the GUI is able to read and convert multiple source files, or if there is a CLI, where I can use a for loop in cmd to process all files in one go...

tebasuna51

12th December 2015, 14:29

this seems to work for single files only...

I can add a option to process all files with the same extension in a folder.
Wait to a new version in UsEac3to thread (http://forum.doom9.org/showthread.php?t=145574).

EDIT: done

Boulder

12th December 2015, 18:22

Is it possible to output the file created during the first pass to some different location than where the actual destination file will be written to? It would make things quite a bit faster if I could output it to a different HD.

arrgh

12th December 2015, 19:28

Thunderbolt8

12th December 2015, 20:28

is eac3to actually multithreaded, does it use multiple cpu cores? I wonder how remux/demux speed would be affected in the not too distant future when PCIe drives hit the 1000MB/s write speed wall.

heerschop

13th December 2015, 17:16

Try building it with GCC.

Thank you for your suggestion. I tried to compile with gcc (mingw) but no luck. I kept keep getting "undefined reference" errors.
I am not a developer so I don't know where to begin to fix these errors.
After fiddling about with visual studio and gcc with no success I give up on building the dcadec.lib.

thanks

Boulder

13th December 2015, 17:36

In Code Generation, you could try enabling the Enhanced Instruction Set option according to your CPU.

heerschop

13th December 2015, 17:59

In Code Generation, you could try enabling the Enhanced Instruction Set option according to your CPU.

In visual studio I have build the libdcadec.dll a zillion times with all sort of settings enabled or disabled. No matter what I did, all my builds were very slow in decoding a dts stream.
I even tried different visual studio versions (2010,2012,2013,2015).

Boulder

13th December 2015, 20:05

Weird..I've just tested with VS2015 and the DLL it creates, doesn't appear to be slow. I didn't make any specific comparisons but looking at the eac3to progress meter, I couldn't tell if the DLL was updated or not.

I have a question of my own: Moonrise Kingdom has a DTS-HD MA track which shows up as 5.0ch but actually is 5.1ch. Decoding with eac3to doesn't proceed because of that, and dcadec.exe reports "Error writing WAV file: PCM output parameters changed". Is there a way to patch the header to make it work?

nevcairiel

13th December 2015, 20:22

I have a question of my own: Moonrise Kingdom has a DTS-HD MA track which shows up as 5.0ch but actually is 5.1ch. Decoding with eac3to doesn't proceed because of that, and dcadec.exe reports "Error writing WAV file: PCM output parameters changed". Is there a way to patch the header to make it work?

It probably changes from 5.0 to 5.1ch somewhere, and if dcadec and eac3to don't handle such changes, there isn't much that can be done.

You could try instructing it to mix to 5.1 always, maybe that helps, not sure.

heerschop

13th December 2015, 20:35

Weird..I've just tested with VS2015 and the DLL it creates, doesn't appear to be slow.

I am new to building with visual studio. This is how I made the build.
- First download and installed Visual studio 2015
- Downloaded the dcadec source files => dcadec-master.zip (from https://github.com/foo86/dcadec )
- extracted the dcadec-master.zip
- opened the dcadec.sln in visual studio
- visual studio asks if I want update the solution to version 140 => Yes
- Build the libdcadec as a release dll. ( The resulting build is smaller in size then the one that came with eac3to)
- Copy the libdcadec.dll to my eac3to folder

Eac3to uses my build without a problem but the decoding is very slow.
Am I missing something or do I use the wrong source files?

Boulder

13th December 2015, 20:39

It seems to change almost immediately because the error message kicks in right after the decoding starts. The -down6 parameter doesn't help here either :(

Music Fan

14th December 2015, 11:24

ffmpeg could maybe decode it.

hightime

15th December 2015, 10:56

Just discovered eac3to (brilliant!) in the context of decode/converting TrueHD. The 7.1 audio I have needs to be converted to 5.1 so I used -down6 but I am curious about how it works. The side channels must get mixed into the back channels but do they also get mixed into the front channels? Also, how is clipping avoided? I converted the audio to a .flac file but this would not load into audacity so I made another conversion to .wav but this appeared to only convert about half the length of the audio. Should I use .pcm instead, or something else? The converted .wav file length is long (over 7 gbytes).

Apologies if these topics have been covered (I searched but couldn't find anything ... and I'm quite new to this ... ).

with thanks.

LigH

15th December 2015, 11:19

WAV is restricted to 32 bit chunk sizes (<4 GB; depending on the interpretation of the first bit as sign, in carelessly programmed tools, possibly even <2 GB). You can try ".wavs" which generates several mono WAV files per channel, location appended to filename. Or try ".w64" for the WAV64 format.

kit90

16th December 2015, 15:44

When eac3to downconverts a 24-bit audio file to 16-bit, it applies Triangular PDF dithering automatically. Does it also apply any noise-shaping?

madshi

16th December 2015, 15:51

No noise shaping, only TPDF dithering.

kit90

16th December 2015, 21:18

No noise shaping, only TPDF dithering.
Thanks :)

ACrowley

21st December 2015, 15:02

Hi

I have a Problem with some AC3 5.1 Tracks from a HDTV TS Capture.
Its surely 5.1 Channel, but eac3to detects it as 2.0 and outputs only 2 Channel Left and Right .wavs

Is there a Way to correct the Header Info in the AC3 or a override in eac3to to Output 6 .wavs ?

thanks

Music Fan

21st December 2015, 15:08

This is maybe 2.0 followed by 5.1 in the same track, it happens on some tv channels (movie in 5.1, ads in 2.0).
TSdoctor can cut audio/video on audio format change but it's not free.

ACrowley

21st December 2015, 15:54

Hi

I cut the TS Streams with Videoredo Frame Accurate

And i tried TS Doctor with the AC3 Function, but eac3to still detects it as 2.0 AC3

EDIT
When i enable the TSDoctor Option Insert Ac3 5.1 Frames if needed then eac3to detects 5.1 AC3 and decodes to 6 CH .wavs

But the demuxed AC3 from this fixed TS Stream shows still 2.0 again ;)

What works: i simply cut a few Single Frames at the Stream Beginning with Videoredo, then its 5.1 Channels :)

Q-the-STORM

24th December 2015, 00:51

you can use ProjectX for that...
Go to PreSettings -> Audio -> check "replace all non-3/2 AC-3 by 3/2lfe silence"

demux the ac3, open it with projectX and click on "Quick Start"...
ProjectX will then replace all 2.0 audio in the track with 5.1 silence, making it possible for eac3to to detect it as 5.1 audio...

a feature like that was actually requested on the VideoReDo forums years ago, but it was never implemented...

Yoshi

27th December 2015, 13:56

I might have found another bug - this time in the decoder used for Dolby TrueHD tracks in conjunction with Dolby Atmos encodings (eac3to 3.31).

In the case of Léon (US Supreme Cinema Series), the decoding of the Atmos track leads to weird cracklings at certain positions whereas the decoding of the embedded AC3 track is flawless.

http://www.bilder-upload.eu/thumb/399a48-1451222081.jpg (http://www.bilder-upload.eu/show.php?file=399a48-1451222081.jpg)

Boulder

27th December 2015, 15:49

Have you tested decoding with a recent ffmpeg build? If it also causes the issue, you need to report the bug to the ffmpeg devs.

Yoshi

27th December 2015, 23:40

Have now. Using ffmpeg-20151227-git-baf4c48-win64-static to decode the thd file demuxed by eac3to, it's the same result.

http://www.bilder-upload.eu/thumb/bcb20c-1451257105.jpg (http://www.bilder-upload.eu/show.php?file=bcb20c-1451257105.jpg)

Guess I better let them know.

Still confused - wasn't the TrueHD decoder to be bug-free so far at least?

nevcairiel

28th December 2015, 10:39

There is no guarantee your TrueHD stream isn't just broken.

Yoshi

28th December 2015, 21:28

@nevcairiel

Which is why I wanted to take some precaution and used the word "might" wisely. Guilty as charged that the source is not really an official one but to double-check this, I used a remuxed one and a nominal 1:1 copy which has to be put together by eac3to.

Just for my defense - NO, I won't buy that movie for the fourth time (two DVDs and the LaserDisc is enough now), just because they finally get a half-way decent video master they could have come up with in the first place (so annoying).

Besides that, I don't consider this Atmos remix to be that great due to its "tinny" acoustics and of course, the 4K remastered Blu-ray doesn't contain the 5.1 mix.

FFmpeg states something about "lossless" check failed, but only with one of the two sources as far as I remember - the crackled PCM result is similar though.

Maybe someone can grab the original and double- (or rather: triple-) check.

Yoshi

30th December 2015, 02:48

Another oddity:

When decoding this DTS-HD MA track, there is some kind of contradiction in the log output of eac3to: on one hand, libDcaDec is allegedly outputting 16 bit data, however the resulting PCM file uses all the 24 bits according to eac3to at the same time.

In any case, the output at least matches the ArcSoft decoder's. Yet again, I don't know if it's really lossless or not.

http://www.bilder-upload.eu/thumb/ff5e1b-1451441001.jpg (http://www.bilder-upload.eu/show.php?file=ff5e1b-1451441001.jpg)

ACrowley

30th December 2015, 12:33

Have anbody here succes with the Sonic Audio Decoder on W7/8.1 x64 ?

I tried v4.2 and 4.3 from the Decoder Pack, also v5 from, Sonic Cinevision.
The Sonic Cinemaster® Audio Decoder 4.3 appears in Directshow registered Filters and i can use it MPC HC etc

But eac3to gives me :

The Sonic Audio Decoder (3.31.0.0) doesn't seem to be installed

I placed the Files in Systems Folder etc etc, nothing helps.
Its a clean System without any Decoder Packages etc.

Is there trick on W8 x64 ? :)

Thanks

dts350z

5th January 2016, 21:34

I would like to resample to 32 bit float, and thus avoid any 2nd pass. Can eac3to do that?

ideally output would be in a format that also supports files larger than 4GB, such as w64 or rf64.

dts350z

6th January 2016, 07:05

Anybody notice that the actual usage output of the current version doesn't show the:

-r8brain use r8brain resampler instead of SSRC

option, unlike the output shown in the post at the top of this thread?

Version number match :confused:

Nico8583

6th January 2016, 13:06

Hi :) I would like to know : what is the best way to convert DTS 5.1 to AC3 5.1 ? Only "eac3to.exe source.dts destination.ac3 -640" ? Or "-normalize" or "-dontPatchDts" are need ? Thank you !

Overdrive80

6th January 2016, 13:23

@madshi

Instead of using r8brain, would not it be better use ffmpeg (soxr)?

http://src.infinitewave.ca/

dts350z

6th January 2016, 16:26

Hi :) I would like to know : what is the best way to convert DTS 5.1 to AC3 5.1 ? Only "eac3to.exe source.dts destination.ac3 -640" ? Or "-normalize" or "-dontPatchDts" are need ? Thank you !

That's a lossy to lossy conversion. Why would you want to do that?

IMHO dts is a better sounding format anyway.

mariner

6th January 2016, 16:52

@kukushka
Maybe we can open a new thread to speak about AAC and muxer/demuxer's (Mp4Muxer/Mp4Box/MkvToolnix/tsMuxeR), but the relevant questions for this thread are clear:

- The directshow Nero 7 decoder, used by eac3to to decode .aac, cut the first 1024 samples (21,333 ms in 48 KHz) in 2.0 and is broken for 5.1.
Take in mind the problem.

- The encoder NeroAacEnc.exe, user by eac3to to encode .m4a, put the correct delay to compensate and can be decoded without problems with NeroAacDec, Qaac or ffmpeg. No problem with it.

- eac3to works fine extracting AAC from MKV/TS/M2TS containers, I obtain the same aac than I muxed previously.
Then, to avoid problems, you can use eac3to to extract and Qaac or ffmpeg to decode (or LWLibavAudioSource inside AviSynth).

Greetings tebasuna51.

Thanks for the post. I'm using eac3to to convert aac to ac3, and struggling to understanding the delay issue. Appreciate if you could assist.

1. If direct from aac to ac3, 5ms silence seems to be inserted. This appears to agree with ffmpeg. Audacity is used for comparing the two.

2. If going from ts/mkv to ac3, Nero Audio Decoder would be used. This would seem to remove 42ms if the audio begins with silence. So the resulting ac3 would be either -37ms shorter or +5ms longer, depending on the initial content.

Does this behavior look correct to you? Is there a way not to use Nero for step 2?

Many thanks and best regards.

tebasuna51

6th January 2016, 17:32

Hi :) I would like to know : what is the best way to convert DTS 5.1 to AC3 5.1 ? Only "eac3to.exe source.dts destination.ac3 -640" ?
Is not the best.
Is correct using eac3to (dcadec) and Aften encoder.

But, talking about free soft, now is better ffmpeg:
ffmpeg -acodec libdcadec -i source.dts -acodec ac3 -center_mixlev 0.707 -surround_mixlev 0.707 -ab 640k destination.ac3

Or "-normalize" or "-dontPatchDts" are need?
Nope.

That's a lossy to lossy conversion. Why would you want to do that?

To save space and/or make compatible with some players, I supose.

IMHO dts is a better sounding format anyway.
Better format? I don't think so.

Talking about size/quality AC3 is better and AAC much better.
Talking about compatibility AC3 is better.

LigH

6th January 2016, 18:01

The "core" dts audio format on DVD Video may be a low-loss format when using the bitrate close to LPCM 16-bit stereo (1536 kbps); but it is not lossless. And the bitrate close to LPCM 16-bit mono (768 kbps) is even audibly lossy. It may use less psycho-acoustic filtering than AC3. But that doesn't make it "better": dts tries to retain even probably inaudible frequencies only "audiophiles" believe to recognize (but couldn't prove), so it possibly lacks in accuracy for audible frequencies instead.

Its purpose was to compress multi-channel audio to bitrates close to comparable usual bitrates of 16-bit LPCM in mono or stereo, and it is still a format based on 16-bit integer samples. Dolby Digital (AC3) instead works with floating point parameters, therefore it may have a better dynamic range if it compresses original 24-bit integer or even floating point samples (important especially for almost slient scenes, like in classical music), keeping the audio audible despite a loss of frequency parts excluded by psycho-acoustic filters, because you will probably not recognize them anyway (except on a rather psychological level).

tebasuna51

6th January 2016, 18:19

1. If direct from aac to ac3, 5ms silence seems to be inserted. This appears to agree with ffmpeg. Audacity is used for comparing the two.
This is the default behaviour for ALL ac3 encoders.
BTW, with Aften, you can avoid the insertion of 5 ms of silence with, for instance:

eac3to INPUT stdout.wav | Aften -b 192 -pad 0 -readtoeof 1 - OUTPUT.ac3

2. If going from ts/mkv to ac3, Nero Audio Decoder would be used. This would seem to remove 42ms if the audio begins with silence. So the resulting ac3 would be either -37ms shorter or +5ms longer, depending on the initial content.
Seems you have misunderstand my post. I say:
"The directshow Nero 7 decoder, used by eac3to to decode .aac, cut the first 1024 samples (21,333 ms in 48 KHz) in 2.0"

Then, always cut 21 ms, and (without -pad 0) finish with 16 ms shorter.

The Nero Audio Decoder (NeroAacDec.exe) is not used by eac3to at all.

Is there a way not to use Nero for step 2?

eac3to only can decode aac with the directshow Nero 7 decoder.

Nico8583

6th January 2016, 21:09

That's a lossy to lossy conversion. Why would you want to do that?

IMHO dts is a better sounding format anyway.

I don't know if I'll convert DTS to AC3 but I feel sound variation are more important on a DTS track than AC3 track. When actors are speaking, the sound is low but when there is action the sound is high so I'm playing with my remote several times ;) but perhaps it's only a feeling or it's not related to DTS.
And also for a compatibility a little bit :D

Is not the best.
Is correct using eac3to (dcadec) and Aften encoder.

But, talking about free soft, now is better ffmpeg:
ffmpeg -acodec libdcadec -i source.dts -acodec ac3 -center_mixlev 0.707 -surround_mixlev 0.707 -ab 640k destination.ac3

So ArcSoft is useless now to decode DTS ? Do you have a conversion commandline sample with dcadec and Aften ?

Nope.
Ok :)

To save space and/or make compatible with some players, I supose.
Yes for compatibility and also for the other reason (see before)

Better format? I don't think so.

Talking about size/quality AC3 is better and AAC much better.
Talking about compatibility AC3 is better.
I don't have test AAC so I don't know about the compatibility but I could test it.

Last question, what about remapping channel ? Is there a risk to have an issue with wrong channel remapping if I convert DTS to AC3 ?

Thank you !

AlexKane

6th January 2016, 21:30

I don't know if I'll convert DTS to AC3 but I feel sound variation are more important on a DTS track than AC3 track. When actors are speaking, the sound is low but when there is action the sound is high so I'm playing with my remote several times ;) but perhaps it's only a feeling or it's not related to DTS.
And also for a compatibility a little bit :D

The dynamic range of the source material (the sound variation you describe above) is intentional. Films are mixed for theaters, not small apartments and tiny TV speakers. Also, i believe DTS, AAC, Vorbis, Opus, etc maintain the dynamic range of the source material, since they don't apply dynamic range compression (DRC).

In the case of AC3, you can use ffmpeg to generate level scaling metadata, but the results are not ideal since obvious pumping artifacts can be introduced during playback.

tebasuna51

6th January 2016, 23:00

...So ArcSoft is useless now to decode DTS ? Do you have a conversion commandline sample with dcadec and Aften ?

Now dcadec is the default decoder for DTS, your sintax is enough:
"eac3to.exe source.dts destination.ac3" (640 Kb/s is the default also)

Last question, what about remapping channel ? Is there a risk to have an issue with wrong channel remapping if I convert DTS to AC3 ?
No problem.

Nico8583

6th January 2016, 23:27

The dynamic range of the source material (the sound variation you describe above) is intentional. Films are mixed for theaters, not small apartments and tiny TV speakers. Also, i believe DTS, AAC, Vorbis, Opus, etc maintain the dynamic range of the source material, since they don't apply dynamic range compression (DRC).

In the case of AC3, you can use ffmpeg to generate level scaling metadata, but the results are not ideal since obvious pumping artifacts can be introduced during playback.
Ok thanks, I believed DTS was the only one to use dynamic range...

Now dcadec is the default decoder for DTS, your sintax is enough:
"eac3to.exe source.dts destination.ac3" (640 Kb/s is the default also
Ok thanks :) but I don't understand why do you say "talking about free soft" for ffmpeg, dcadec and Aften are commercial softwares ?

mariner

7th January 2016, 10:46

Thanks for the kind reply, tebasuna51.

1.
This is the default behaviour for ALL ac3 encoders.
BTW, with Aften, you can avoid the insertion of 5 ms of silence with, for instance:

eac3to INPUT stdout.wav | Aften -b 192 -pad 0 -readtoeof 1 - OUTPUT.ac3

So, this would work for IN.aac -> OUT.ac3?
eac3to IN.aac stdout.wav | Aften -b 192 -pad 0 -readtoeof 1 - OUT.ac3

Would you also kindly provide a CLI for IN.mkv -> OUT.ac3, perhaps using ffmpeg if not possible with eac3to?

2.
"The directshow Nero 7 decoder, used by eac3to to decode .aac, cut the first 1024 samples (21,333 ms in 48 KHz) in 2.0"
Then, always cut 21 ms, and (without -pad 0) finish with 16 ms shorter.

As I'd explained, Audacity here would indicate 42ms cut, not 21ms. And only if there's silence at the beginning. Otherwise, everything is preserved by the Nero DS decoder.

So if the following command is run, the output delay is either -37ms or +5ms depending on the content.

What might be causing such unusual behavior?

eac3to IN.mkv 2: OUT.ac3

3.
eac3to only can decode aac with the directshow Nero 7 decoder.
That's interesting, given Eac3to uses libAften for decoding aac when converting aac to ac3.
Any reason?

Many thanks and best regards.

tebasuna51

7th January 2016, 11:19

...but I don't understand why do you say "talking about free soft" for ffmpeg, dcadec and Aften are commercial softwares ?
The DTS decoder dcadec (inside ffmpeg and eac3to) is also free soft.

The AC3 encoder inside ffmpeg is better than Aften encoder, both free soft, but maybe there are better certified Dolby Digital commercial encoders.

I say "maybe" because I don't know test about that.

tebasuna51

7th January 2016, 15:06

1.1
So, this would work for IN.aac -> OUT.ac3?
eac3to IN.aac stdout.wav | Aften -b 192 -pad 0 -readtoeof 1 - OUT.ac3
3.
That's interesting, given Eac3to uses libAften for decoding aac when converting aac to ac3.
Don't mistake decoder and encoder.
libAften is only a AC3 encoder, can't decode aac, that only work if you have installed the directshow Nero 7 decoder.

Recommended command line:
eac3to IN.aac -192 OUT.ac3
or
eac3to IN.mkv 2: -192 OUT.ac3

Both produce an AC3 with firts 21 ms cutted and 5 ms delayed (16 ms shorter).
You can add the parameter +16ms to both command lines to obtain the first 21 ms replaced by silence.
1.2
Would you also kindly provide a CLI for IN.mkv -> OUT.ac3, perhaps using ffmpeg if not possible with eac3to?
ffmpeg -i IN.aac -c:a ac3 -b:a 192k OUT.ac3
ffmpeg -i IN.mkv -map 0:1 -c:a ac3 -b:a 192k OUT.ac3
ffmpeg -i IN.mp4 -map 0:1 -c:a ac3 -b:a 192k OUT.ac3

All AC3 with the standard ac3 5 ms delay of silence.

2. As I'd explained, Audacity here would indicate 42ms cut, not 21ms. And only if there's silence at the beginning. Otherwise, everything is preserved by the Nero DS decoder.

So if the following command is run, the output delay is either -37ms or +5ms depending on the content.

What might be causing such unusual behavior?
Audacity don't use the Nero DS decoder to decode AAC, it use ffmpeg.

And in all my test opening IN.aac or IN.mkv or IN.mp4 the decoded aac is perfect, without any cut or delay.

I don't know how you obtain these data. Please explain your workflow.

Thunderbolt8

9th January 2016, 00:03

madshi, could we please get an update for dcadec? it has reached v0.2. I know we could do it ourselves but as others have reported for some reason the .dll we produce seems to work slower than yours.

mariner

9th January 2016, 08:50

Thanks for the kind reply,

1.

Recommended command line:
eac3to IN.aac -192 OUT.ac3
or
eac3to IN.mkv 2: -192 OUT.ac3

Both produce an AC3 with firts 21 ms cutted and 5 ms delayed (16 ms shorter).
You can add the parameter +16ms to both command lines to obtain the first 21 ms replaced by silence.

ffmpeg -i IN.aac -c:a ac3 -b:a 192k OUT.ac3
ffmpeg -i IN.mkv -map 0:1 -c:a ac3 -b:a 192k OUT.ac3
ffmpeg -i IN.mp4 -map 0:1 -c:a ac3 -b:a 192k OUT.ac3

All AC3 with the standard ac3 5 ms delay of silence.

Is there a way to use -pad 0 with ffmpeg?

2.
Audacity don't use the Nero DS decoder to decode AAC, it use ffmpeg.

And in all my test opening IN.aac or IN.mkv or IN.mp4 the decoded aac is perfect, without any cut or delay.

I don't know how you obtain these data. Please explain your workflow.

The workflow is quite straight forward:
eac3to IN.mkv 2: OUT.ac3
Audacity is only used to display the waveforms. Assuming the absence of idiosyncrasy of any kind, it's a simple matter to read off the relative delays between the aac and ac3.

I have uploaded two 10sec samples for your testing pleasure. The first has the remarkable ability to survive Nero's molestation, while the other has a sampling frequency of 48000/24000, which may explain the 42ms truncation instead of 21ms. Perhaps a spectrum analyzer would tell if it is indeed band limited.

Many thanks and best regards.

Nico8583

9th January 2016, 11:34

The DTS decoder dcadec (inside ffmpeg and eac3to) is also free soft.

The AC3 encoder inside ffmpeg is better than Aften encoder, both free soft, but maybe there are better certified Dolby Digital commercial encoders.

I say "maybe" because I don't know test about that.
Thank you, I'll look at this.
A last question, why do you use "-center_mixlev 0.707 -surround_mixlev 0.707" with ffmpeg ?

tebasuna51

9th January 2016, 13:49

Is there a way to use -pad 0 with ffmpeg?
At least is not ducumented that option:
https://ffmpeg.org/ffmpeg-all.html#ac3-and-ac3_005ffixed

I have uploaded two 10sec samples...

You are right, using your samples I obtain cuts of 0 and 32 ms.
Even with other samples until 54 ms cut.

Then I edited my post http://forum.doom9.org/showthread.php?p=1747412#post1747412 and now must be:

- The directshow Nero 7 decoder, used by eac3to to decode .aac, make unpredictables cuts (from 0 to 54 ms at least) in 2.0 and is broken for 5.1.

But this is still valid:

- eac3to works fine extracting AAC from MKV/TS/M2TS containers, I obtain the same aac than I muxed previously.
Then, to avoid problems, you can use eac3to to extract and Qaac or ffmpeg to decode (or LWLibavAudioSource inside AviSynth).

tebasuna51

9th January 2016, 14:05

... why do you use "-center_mixlev 0.707 -surround_mixlev 0.707" with ffmpeg ?

By default ( https://ffmpeg.org/ffmpeg-all.html#ac3-and-ac3_005ffixed ) ffmpeg put -center_mixlev 0.595 -surround_mixlev 0.500:

8.2.1.2 Downmix Levels
----------------------
-center_mixlev level

Center Mix Level. The amount of gain the decoder should apply to the center channel when downmixing to stereo. This field will only be written to the bitstream if a center channel is present. The value is specified as a scale factor. There are 3 valid values:

0.707 Apply -3dB gain
0.595 Apply -4.5dB gain (default)
0.500 Apply -6dB gain

-surround_mixlev level

Surround Mix Level. The amount of gain the decoder should apply to the surround channel(s) when downmixing to stereo. This field will only be written to the bitstream if one or more surround channels are present. The value is specified as a scale factor. There are 3 valid values:

0.707 Apply -3dB gain
0.500 Apply -6dB gain (default)
0.000 Silence Surround Channel(s)
-center_mixlev 0.707 -surround_mixlev 0.707 is the Aften default.

I recommend use -center_mixlev 0.707 to avoid the low dialog volume when is downmixing to stereo. You can let the default -surround_mixlev or even 0.000 at your preference.

Nico8583

9th January 2016, 14:26

Ok thank you, perhaps it could solved dynamic range I can find on DTS track

mariner

11th January 2016, 11:10

Thanks for the kind reply, tebasuna51.

1.
At least is not ducumented that option:
https://ffmpeg.org/ffmpeg-all.html#ac3-and-ac3_005ffixed

Thanks for the link. Can ffmpeg add +/- delay like eac3to?

2.

- The directshow Nero 7 decoder, used by eac3to to decode .aac, make unpredictables cuts (from 0 to 54 ms at least) in 2.0 and is broken for 5.1.

Perhaps madshi can be persuaded to consider other candidates for aac decoding?

Many thanks and best regards.

tebasuna51

11th January 2016, 18:37

Thanks for the link. Can ffmpeg add +/- delay like eac3to?
You can search at same doc page.
For add +delay: https://ffmpeg.org/ffmpeg-all.html#toc-adelay
To add 500 ms delay to a 6 channel audio add this to command line:

-af adelay=500|500|500|500|500|500

For add -delay: https://ffmpeg.org/ffmpeg-all.html#toc-atrim
To cut fisrt 50 ms to an audio add this to command line:

-af atrim=0.05

Perhaps madshi can be persuaded to consider other candidates for aac decoding?

He don't want add libav aac decoder because license copyright problems.

jpsdr

12th January 2016, 19:24

madshi, could we please get an update for dcadec?

Just out of curiosity, can you try and test here (https://mega.nz/#!ZRk1FLxL!tkKYzbipYjTjNgX7unRCCkwkaq3H7lvIARqI-YpDPm4) ?
I've change some compiler options, to make a build, theoricaly, more efficient.
The Intel version is compiled with Intel compiler, and needs a CPU with AVX2 instructions.

-TiLT-

15th January 2016, 05:57

Is edit limited to one socond precision? -edit=h:mm:ss,+-delayms
Or is there any way to work with a higher precision? Sth. like -edit:=h:mm:ss:msm,+-delayms?

In several scenaerios, I just want to cut out one or two AC3 frames at a very precise position or insert some silent frames (looping is actually not always an option), but there seem to be no tools out there for such tasks.

Music Fan

15th January 2016, 11:59

In several scenaerios, I just want to cut out one or two AC3 frames at a very precise position or insert some silent frames (looping is actually not always an option), but there seem to be no tools out there for such tasks.
Maybe Delaycut.

LigH

15th January 2016, 12:34

Or HeadAC3he; but it's rather old, hard to find nowadays.

Oh, look, a signature! :eek:

tebasuna51

15th January 2016, 13:03

Is edit limited to one socond precision? -edit=h:mm:ss,+-delayms
Or is there any way to work with a higher precision? Sth. like -edit:=h:mm:ss:msm,+-delayms?

You can use -edit:=h:mm:ss.msm,+-delayms

But remember than eac3to (or DelayCut) only work adding/deleting frames (32 ms for samplerate 48 KHz).
Then the edit point, and delay value, are rounded to near value (precision +- 16 ms)

Is not possible better precision without recode.

Yoshi

20th January 2016, 00:59

Due to the circumstances, I encountered yet another movie example where I wonder if the decoding is correctly done by eac3to/ffmpeg or not.

"Everest" comes with a 7.1 TrueHD Atmos track which is, decoded to 7.1 FLAC full of clipping in certain scenes.

For the sake of comparison, I extracted the AC3 core and let that one decode to 5.1 PCM. While eac3to suggests a gain of -6.2dB after encountering clipping and recognizing it as such, the result looks just as bad as the "lossless" one (as I learned, this seems to be a relative term when it comes to multichannel audio in conjunction with TrueHD and DTS-HD MA), only more quiet of course.

Here is twice the left channel of the soundtrack.

http://www.bilder-upload.eu/thumb/35c338-1453249010.jpg (http://www.bilder-upload.eu/show.php?file=35c338-1453249010.jpg)

Now I wonder: is that particular clipping already contained in the mix (and maybe even intended) or is it screwed up during decoding? In other words: how can I be sure which type of clipping I'm dealing with - the immanent one or the artificial one introduced by bugs or difficulty of the decoding itself thanks to the floating point vs. integer dilemma?

torturesauce

20th January 2016, 08:56

tebasuna51

20th January 2016, 12:43

The foobar2000 developer for the DTS plugin had abandoned support of dcadec and reverted back to the old DTS codec because dca was too slow and buggy at the time. Can somebody please make a fork or something with the latest dcadec so I can run some tests with it?
Buggy for what? Is this the problem?
Problems almost entirely resulting from the switch to an incomplete implementation such as dcadec, which not only did not have any implementation for the common 14 bits data / 2 bits padding per 16 bit word format of most older DTS streams, it also fails to recognize some DTS CDs outright. It's also significantly slower at decoding.

That's don't affect at all to DTS movie trakcs, and the problem can be solved with a data parser to restore the standard 16 bits/word DTS format.
The old BeSplit can do the job without problems.

Maybe this is important for Foobar2000 but not here, and the old DTS decoder foobar plugin don't support DTS-HD at all, at least in my test.

torturesauce

20th January 2016, 13:05

Buggy for what? Is this the problem?

That's don't affect at all to DTS movie trakcs, and the problem can be solved with a data parser to restore the standard 16 bits/word DTS format.
The old BeSplit can do the job without problems.

Maybe this is important for Foobar2000 but not here, and the old DTS decoder foobar plugin don't support DTS-HD at all, at least in my test.

Yes, that's it. It had serious issues with DTS CDs. And there is an old foobar plugin for DTS-HD. (http://sourceforge.net/projects/dvdadecoder/files/foo_input_dtshd/) Okay, I guess I'll ask about it on Hydrogenaudio instead of here. Thanks!

tebasuna51

20th January 2016, 14:13

Yes, that's it. It had serious issues with DTS CDs.
Then use before BeSplit.
And there is an old foobar plugin for DTS-HD. (http://sourceforge.net/projects/dvdadecoder/files/foo_input_dtshd/)
I tested already this old plugin:
foo_input_dtshd-0.1.3.zip 2011-03-19

known_issues.txt from this page:
All the mentioned below is related to current version only.

1. Decoder adds 2048 zero samples before track.
2. Decoder cuts 1-2 seconds at the end of the track.
3. Surround channels are -3dB of what is encoded.
4. Decoder doesn't play DTS9624 streams.

nevcairiel

20th January 2016, 14:26

That's don't affect at all to DTS movie trakcs, and the problem can be solved with a data parser to restore the standard 16 bits/word DTS format.
The old BeSplit can do the job without problems.

libdcadec even has a parser for such a conversion, sounds to me like the developer of this foobar plugin just gave up without checking too much.

tebasuna51

20th January 2016, 15:28

Now I wonder: is that particular clipping already contained in the mix...?

I think so. Is not the first time than similar clip are in source tracks (even with DTS-MA encodes).

osso123

20th January 2016, 19:21

Hello everybody, i noticed that a converted AC3 subwoofer/LFE track sounds different to the original DTS track. The conversion by eac3to (aften) adds harmonics (?) to the track it seems. I attached a audacity screenshot to this post, please have a look yourself; maybe someone can explain what is going on.

Thank you :)

Picture shows:
Bottom track is the original DTS track with a very deep & clear bass; the top track is the convertion result in ac3 format which has frequencies (harmonics?) added.

torturesauce

20th January 2016, 20:50

Then use before BeSplit

Yeah, I would, but it doesn't matter anymore. I lost the version of the plugin that used dcadec, since the developer forced it to be deprecated. Anyway, thank you for all the info! Let's hope that foobar supports dcadec again in the future.

filler56789

20th January 2016, 22:04

Let's hope that foobar supports dcadec again in the future.

OR you can pester Maxim Anisiutkin and try to make things happen faster :sly:

Emulgator

21st January 2016, 03:43

Osso, which bitrate for DTS and which bitrate for AC-3 ? Number of Channels for the complete encode ?

tebasuna51

21st January 2016, 16:27

libdcadec even has a parser for such a conversion,...

There are 4 valid formats for DTS:

16_BE: data with 16 valid bits/word and Big Endian order
14_LE: data with 14 valid bits/word and Little Endian order
14_BE: data with 14 valid bits/word and Big Endian order
16_LE: data with 16 valid bits/word and Little Endian order

We can use ffdcaenc to obtain samples of 4 formats using some encoder parameters.
I tested the 4 samples and try to decode with eac3to and ffmpeg -acodec libdcadec:

DTS first 4 bytes ffdcaenc eac3to ffmpeg where is?
----- ------------- -------- ------- ------ ---------------
16_BE 7FFE8001 default OK OK standard BD/DVD
14_LE FF1F00E8 -e -r (1) OK standard DTS-CD
14_BE 1FFFE800 -r Invalid OK I don't know
16_LE FE7F0180 -e Invalid (2) I don't know

(1) Like DTS is not recognized (Invalid), but with a WAV header show DTSWAV and is decoded fine with LibDcaDec.
But some DTSWAV from DTS-CD have garbage before the first valid DTS header in DATA chunk of WAV, and is not recognized by eac3to.
I don't know if this garbage is a requirement for SPDIF output of DTS-CD.
A workaound for eac3to can be force read DATA WAV, with a new parameter -dts, until found the header FF1F00E8.

(2) I found some problems decoding 16_LE, but still I'm not sure if is a ffdcaenc or libdcadec problem.
EDIT: seems than ffmpeg -acodec libdcadec have problems (lose frames) with odd DTS Framesize (typical 2013 for instance).
Like a never see a real 16_LE I think that is not important.

Then libdcadec seems work fine with 14 bits/word DTS formats.

filler56789

22nd January 2016, 05:32

There are 4 valid formats for DTS:

16_BE: data with 16 valid bits/word and Big Endian order
14_LE: data with 14 valid bits/word and Little Endian order
14_BE: data with 14 valid bits/word and Big Endian order
16_LE: data with 16 valid bits/word and Little Endian order

We can use ffdcaenc to obtain samples of 4 formats using some encoder parameters.

One can also use bsconvert.exe:

=>bsconvert
Bitstream converter
===================
This utility conversts files between numerous MPA/AC3/DTS stream types:
SPDIF padded, 8/14/16bit big/low endian. By default, it converts any
stream type to the most common byte stream.

This utility is a part of AC3Filter project (http://ac3filter.net)
Copyright (c) 2007-2013 by Alexander Vigovsky

Usage:
Detect file type and print file information:
> bsconvert input_file

Convert a file:
> bsconvert input_file output_file [format]

Options:
input_file - file to convert
output_file - file to write result to
format - output file format:
8 - byte stream (default)
16le - 16bit low endian
14be - 14bit big endian (DTS only)
14le - 14bit low endian (DTS only)

NOTICE: regarding the 14-bit formats — 'ideally' at least, the "apparent" bitrate must be an integer multiple of 8, so that the `effective´ bitrate is exactly

(7/8) × |apparent_bitrate|

Examples:

1234.8kbps ÷ (7/8) = 1411.2kbps

1344kbps ÷ (7/8) = 1536kbps

and so on.

tebasuna51

22nd January 2016, 10:51

One can also use bsconvert.exe...

Yep, I mentioned BeSplit to show than is a issue well know longtime ago.

an3k

22nd January 2016, 11:18

Thanks for that great tool. I really helps a lot!

I have this file:eac3to.exe "E:\S01E01_a_eng.dts"
DTS Master Audio, 5.1 channels, 16 bits, 48kHz
(core: DTS, 5.1 channels, 1509kbps, 48kHz)

eac3to.exe "E:\S01E01_a_eng.dts" "E:\S01E01_a_eng.ac3" -640DTS Master Audio, 5.1 channels, 16 bits, 48kHz
(core: DTS, 5.1 channels, 1509kbps, 48kHz)
Decoding with libDcaDec DTS Decoder...
libDcaDec reported the warning "XLL output not lossless".
Remapping channels...
Encoding AC3 <640kbps> with libAften...
Creating file "E:\S01E01_a_eng.ac3"...
The original audio track has a constant bit depth of 16 bits.
eac3to processing took 2 minutes, 26 seconds.
Done.

eac3to.exe "E:\S01E01_a_eng.dts" "E:\S01E01_a_engcore.ac3" -640 -coreDTS Master Audio, 5.1 channels, 16 bits, 48kHz
(core: DTS, 5.1 channels, 1509kbps, 48kHz)
Extracting DTS core...
Decoding with libDcaDec DTS Decoder...
Patching bitdepth to 24 bits...
Remapping channels...
Encoding AC3 <640kbps> with libAften...
Creating file "E:\S01E01_a_engcore.ac3"...
The original audio track has a constant bit depth of 24 bits.
eac3to processing took 1 minute, 46 seconds.
Done.

I also ran the second command again but with -core -640 (I thought there may be a difference). All three files are exactly the same regarding size (278.924.800 Bytes) and format (MediaInfo and GSpot). Why are the files identical when the second command shows "Patching bitdepth to 24 bits..." while the first command doesn't? Are the resulting files actually 24 bits or 16 bits or something else? Is the first command re-encoding the DTS-HD to AC3 while the second just uses DTS to AC3? If so, how come the resulting files are identical?

Please enlighten me :)

nevcairiel

22nd January 2016, 11:28

Decoding the lossy core only will always result in 24-bit audio, while decoding the lossless part will results in the specified bitdepth.
So yes, the first command encodes the DTS-HD lossless part into AC3, and the second only encodes the DTS lossy core into AC3. However, due to the lossy AC3 encoding, its not entirely unlikely that the result would be largely identical.

Note that AC3 doesn't have a "bitdepth" as such, so feeding it 24-bit data in contrast to 16-bit data won't actually change much how the AC3 file turns out.

an3k

22nd January 2016, 11:51

osso123

22nd January 2016, 12:15

Osso, which bitrate for DTS and which bitrate for AC-3 ? Number of Channels for the complete encode ?

I attach an audio test file in wav format to this post, please have a look. It is mono, 48Hz.

This resulting output file has no harmonics (?) added:
eac3to test.wav out320.ac3 -320

But this version (and all below increasingly heavy) has - it seems to be depending on bitrate:
eac3to test.wav out192.ac3 -192

I used different codecs to replicate, but ogg/mp3 show no frequency "overshoot" down to very low bitrates (f.i. 32kb).
So, is this normal for AC3 codec to introduce massive noise/overshoot/harmonics even at midrange bitrates? This happens too when I used Audacityc export feature as well by the way.

hello_hello

22nd January 2016, 15:04

So if AC3 doesn't have a bitdepth why does eac3to makes a difference here? The first command created a 16-Bit AC3 and the second created a 24-Bit AC3 but both resulting files are identical.

In other words: When in doubt always encode the DTS-HD stream (instead of the DTS core) to AC3 and don't care about the given bitdepth info at all?

Lossy audio doesn't have a fixed bitdepth.
Bitrate = the number of samples per second. For lossless audio bitdepth = the range of values that can be assigned to any one of those samples. For 8 bit it's 256, for 16 bit it's 65,536 and for 24 bit it's 16,777,216.

I'd assume because the DTS-HD audio is lossless the bitdepth is known. For your example it was originally 16 bit, it was encoded at 16 bit, and eac3to decoded it as 16 bit and fed that to the AC3 encoder. DTS-HD supports 24 bit lossless, but it appears you have 16 bit DTS-HD.
It's kind of like converting a 16 bit wave file to a 16 bit flac file and then back to a 16 bit wave file again. Nothing is lost, and in your first example you've effectively converted that second wave file to AC3.

Lossy audio can be decoded to any fixed bitdepth. The greater the bitdepth, the more accurately it can be decoded. eac3to decodes the lossy DTS core, which has no fixed bitdepth, to a fixed bitdepth of 24 bits.
It's kind of like converting a 16 bit wave file to an MP3 and then decoding the MP3 to a 24 bit wave file. What was lost during the MP3 conversion is gone forever despite the output bitdepth being greater.

The size of a file doesn't tell you much. Encoding five minutes of silence at 640kbps will give you the same file size as encoding music at 640kbps. The bitrate is the same. 640kbps is 640kbps.

tebasuna51

22nd January 2016, 22:54

So, is this normal for AC3 codec to introduce massive noise/overshoot/harmonics even at midrange bitrates?

Sorry but I can't replicate your test, the differences between your Test.wav and the AC3 192 Kb/s are below than -61 dB (0.09 %).

That is not massive noise/overshoot/harmonics, is the expected difference between source and a lossy encode.

osso123

22nd January 2016, 23:08

Sorry but I can't replicate your test, the differences between your Test.wav and the AC3 192 Kb/s are below than -61 dB (0.09 %).

That is not massive noise/overshoot/harmonics, is the expected difference between source and a lossy encode.

Please look at the resulting ac3 files spectrum via audacity. It shows harmonic frequencies added that werent there before. In this example there are only few new frequencies added (even more if you reduce the conversion bitrate), but if you run this test with a real life file, for example of a movie, you will see extreme differences, you can even *hear* them by ear, which i think is unacceptable. :(

P.S. these reply-submission-captchas are ... overpowered :/

osso123

22nd January 2016, 23:22

I uploaded a better example of a 5.1 DTS real-life file and the converted ac3 file.

Load those files into your audio editor and just listen only to the bass tracks (solo). You will hear those new frequencies instantly, they are distorting the bass channel.

http://www98.zippyshare.com/v/6ViEaKpO/file.html

tebasuna51

23rd January 2016, 13:10

I uploaded a better example of a 5.1 DTS real-life file and the converted ac3 file.

Seems there are something wrong in your real-life DTS.
I don't know the encoder used to create this DTS, but is it than have high frequency harmonics and not the AC3. See attached image.

Maybe sound better for you, but the AC3 encoder do the job like expected:
filtering high frecuencies before encode.

osso123

23rd January 2016, 14:37

Seems there are something wrong in your real-life DTS.

Or maybe you named the files wrong? Please look at this video capture I just did:
https://youtu.be/2gHP_SOZS6Y

If you have a mediaplayer that can remap/mute audio inputchannels separately - like MPC (mediaplayerclassic) - you could also just have it mute all but the LFE channel and listen to it that way. The high pitch frequencies in the ac3 are hearable from far away. So its no visual bug in Audacity or something of that sort. ;)

P.S. btw, my spectrogram windows-size in audacity is set to 4096.

tebasuna51

23rd January 2016, 18:40

Or maybe you named the files wrong?
I only renamed the ac3 (osso) because I make other encodes to AC3 (with Aften and ffmpeg) with the same result.

The DTS remain with the same name downloaded (orig).

Maybe the problem is your Audacity decoders.
I decoded the compressed formats (out of Audacity) to wavs, and only load in Audacity decompressed wav files.

I decoded the DTS with eac3to using libdcadec and ArcSoft and both show the same problem. The AC3 decoded with eac3to libav.

Try using that method because your DTS spectrogram seems limited to 300 Hz, but mine go until 3000 Hz and more, and I don't see problems with AC3 spectrogram (like you show in video) also until 3000 Hz.

EDIT:
Using my Audacity decoders (ffmpeg-win-2.2.2), both spectrograms go until 3000 Hz but seems fine:
The DTS don't have high harmonics and the AC3 is equal to the DTS without the problems in your video.

an3k

23rd January 2016, 21:22

Lossy audio doesn't have a fixed bitdepth.
Bitrate = the number of samples per second. For lossless audio bitdepth = the range of values that can be assigned to any one of those samples. For 8 bit it's 256, for 16 bit it's 65,536 and for 24 bit it's 16,777,216.Oh, I thought (for lossless audio) kHz defines how much samples per second are taken and Bit depth how many values each sample stores. And I thought AC-3 would work like eg. x264 which keeps the bitrate low when there is no content to encode. So in short AC-3 is like MP3 CBR?!

I'd assume because the DTS-HD audio is lossless the bitdepth is known. For your example it was originally 16 bit, it was encoded at 16 bit, and eac3to decoded it as 16 bit and fed that to the AC3 encoder. DTS-HD supports 24 bit lossless, but it appears you have 16 bit DTS-HD.I have other files. Some with 24-Bit DTS-HD and 16-Bit DTS Core, some with 16-Bit DTS-HD and 24-Bit Core and last but not least 16-Bit/16-Bit as well as 24-Bit/24-Bit. I just re-checked with MediaInfo and even for (lossy) DTS I get a Bitdepth shown.

It's kind of like converting a 16 bit wave file to a 16 bit flac file and then back to a 16 bit wave file again. Nothing is lost, and in your first example you've effectively converted that second wave file to AC3.

Lossy audio can be decoded to any fixed bitdepth. The greater the bitdepth, the more accurately it can be decoded. eac3to decodes the lossy DTS core, which has no fixed bitdepth, to a fixed bitdepth of 24 bits.
It's kind of like converting a 16 bit wave file to an MP3 and then decoding the MP3 to a 24 bit wave file. What was lost during the MP3 conversion is gone forever despite the output bitdepth being greater.Yeah, that is the part I already knew. I ripped my Audio-CDs with the Fraunhofer MP3 codec when it was leaked back then and still do some re-encodings today from CD to FLAC. Also read (and understood = the important part ;)) https://www.highresaudio.com/texte.php?ca_id=92

One last question: In http://forum.doom9.org/showthread.php?t=27131 I read that based on the bitrate AC-3 limits the available frequency range, eg. 256 kbps up to 12 kHz, 384 kbps up to 18 kHz and 448 kbps or higher with full 20 kHz. Is that true? I thought that a 2 channel 224 kbps AC-3 has a better quality per channel than a 6 channel 640 kbps AC-3. Maybe I should just go with 640 regardless of the amount of channels? :)

tebasuna51

23rd January 2016, 23:51

So in short AC-3 is like MP3 CBR?!
More or less, yes.

I have other files. Some with 24-Bit DTS-HD and 16-Bit DTS Core, some with 16-Bit DTS-HD and 24-Bit Core and last but not least 16-Bit/16-Bit as well as 24-Bit/24-Bit. I just re-checked with MediaInfo and even for (lossy) DTS I get a Bitdepth shown.
Lossy DTS (Core) don't have bitdepth, and MediaInfo is wrong when show that info (and others infos).

I read that based on the bitrate AC-3 limits the available frequency range, eg. 256 kbps up to 12 kHz, 384 kbps up to 18 kHz and 448 kbps or higher with full 20 kHz. Is that true?

Is a encoder option, but is recommended for 5.1.

For 2.0: 112 Kb/s up to 12.4 KHz, 160 Kb/s up to 15.8 KHz, 192 Kb/s or higer up to 20.3 KHz

LigH

24th January 2016, 22:02

In general, without auxiliary specifications, you can use AC3 in VBR mode too (I believe Aften supported that). But there are consumer media specifications (e.g. "DVD Video") which require CBR audio streams. AC3 can, but is not allowed to under certain circumstances.

For audio formats with a good "channel coupling" (known as "Mid/Side" encoding for MP3 which supports stereo at most, but it can be handled in a similar way for more channels too), there is a theorem that the bitrate shall be in relation to the square root of the number of full frequency channels to achieve similar quality. It usually works quite well for AC3, comparing a 2.0 bitrate as √2 times a theoretical base mono bitrate with a 5.1 bitrate as √5 times the same theoretical base mono bitrate. Depending on the content.

an3k

25th January 2016, 11:06

Thank you very much both of you for your time explaining that stuff

More or less, yes.

Lossy DTS (Core) don't have bitdepth, and MediaInfo is wrong when show that info (and others infos).Jeez, I thought that at least this tool does it right. I used GSpot some years ago and was told it shows wrong information and that I should use MediaInfo instead. Is there a tool that shows the information correctly?

Is a encoder option, but is recommended for 5.1.

For 2.0: 112 Kb/s up to 12.4 KHz, 160 Kb/s up to 15.8 KHz, 192 Kb/s or higer up to 20.3 KHzOverall bitrate I guess!?!

I found

http://i.imgur.com/3iOylDA.png

but to be honest I didn't understood much. So to be on the "save side" (=no frequency limiting) one should use at least 448 kbps for 5.1 or 192 kbps for 2.0?!? For 4.0 do I just have to double the bitrate of 2.0 and for mono just halve it?

In general, without auxiliary specifications, you can use AC3 in VBR mode too (I believe Aften supported that). But there are consumer media specifications (e.g. "DVD Video") which require CBR audio streams. AC3 can, but is not allowed to under certain circumstances.Good to know VBR is possible. But that would not increase quality but only create smaller files because AC-3 is limited to 640 kbps and even VBR will not exceed this?!

For audio formats with a good "channel coupling" (known as "Mid/Side" encoding for MP3 which supports stereo at most, but it can be handled in a similar way for more channels too), there is a theorem that the bitrate shall be in relation to the square root of the number of full frequency channels to achieve similar quality. It usually works quite well for AC3, comparing a 2.0 bitrate as √2 times a theoretical base mono bitrate with a 5.1 bitrate as √5 times the same theoretical base mono bitrate. Depending on the content.I believe I think I understood this ... EDIT: After some testing I know I did not. English + mathematical terms aren't my hobby :)

LigH

25th January 2016, 11:31

It just means: To have 5.x sound as good as 2.0 at e.g. 224 kbps, you don't need 5/2 times the bitrate (224*5/2=560, next closest available block bitrate would be 576 kbps), but only about √5/√2 times as much (224*√5/√2~354 kbps, next closest available block bitrate would be 384 kbps). Well, channel coupling isn't really that good (the more channels, the more an accurate phase angle is important to avoid flanging effects). A 384 kbps discrete 5.1 AC3 sounds not certainly as good as a comparable 224 kbps ProLogic 2.0 AC3, better to have 448 kbps. And 640 kbps is even ... "generous", in comparison.

tebasuna51

25th January 2016, 13:28

...I should use MediaInfo instead. Is there a tool that shows the information correctly?
MediaInfo is wrong when show:
Bit depth : 24 bits
The real info contained in the DTS header field is:
Source PCM Resolution : 24

That is, the bitdepth of the PCM source (WAV or equivalent) used to encode the DTS.

When encode, the PCM samples in time domain are converted to float samples in frequency domain, and someones are discarded in lossy encodes (by frecuency cutoff or low values) to fit in the bitrate assigned.

At this moment the bitdepth of the source have no meaning at all.

Even some encoders put always 24 in this header field, no mather the source was 16 bits.
Also eac3to, when extract DTS's, put always 24 in this field, thats force some decoders (than read this field) to output at least 24 bit.

For all that we need forget the bitdepth info of lossy encodes.
Only DTS have this info field, all other lossy encoders don't show that irrelevant info.

So to be on the "save side" (=no frequency limiting) one should use at least 448 kbps for 5.1 or 192 kbps for 2.0?!?
Yep, but remember than high frequency limit is not the unique quality parameter.

Like I say before some samples in frequency domain must be discarded to fit in the bitrate, if aren't by frequency must be by low values and lose precission.

Good to know VBR is possible.
Possible but not compatible with all players.

Before than try AC3 VBR I recommend AAC or MP3 VBR for 2.0
For 5.1 you can try AAC or E-AC3 (maybe a player than support AC3 VBR support also E-AC3 much better)

an3k

26th January 2016, 11:21

...

...

Now I understand how it works. Thank you both very much for not letting me die stupid :)

One last quick question: Is there an easy way to strip the EX out of a "AC3 EX, 5.1 channels, 2:23:11, 640kbps, 48kHz" source? Currently I convert to WAV then back to AC3 and in that process (and only then) I get Reducing depth from 64 to 24 bits... (64 bit AC-3 file?! Interesting ;)) as well as Clipping detected, a 2nd pass will be necessary.

tebasuna51

26th January 2016, 16:02

Is there an easy way to strip the EX out of a "AC3 EX, 5.1 channels, 2:23:11, 640kbps, 48kHz" source?
The EX in AC3 is not related with next questions.

It say: "There are a Back Center channel mixed in surround channels"
Like DTS-ES 5.1 matrixed.

I get Reducing depth from 64 to 24 bits...
The AC3 decoder output PCM samples 64 bits float, then is downconverted to 24 bits int because is enough precission for PCM from a lossy encode.

You can use the parameter -full to output the 64 bits float PCM.

as well as Clipping detected, a 2nd pass will be necessary.
Sometimes the decoder output go over 0dB than can't be downconverted to 24 int without clip peaks.

You can use the parameter -no2ndpass to avoid the second pass.

Is, more or less, safe because peaks over 0dB can only be imperfections of lossy encoder/decoder. The original source can't have peaks over 0dB.

Thunderbolt8

30th January 2016, 14:25

The German (3D) BD of Inside Out (seamless branching) has a EAC3 7.1 stream with 896kbps and which has as embedded core stream AC3 5.1 with 512kbps. I want to extract just that ac3 core as it is without any reencoding. but when I do with the cmd "eac3to 1) X: C:\stream.ac3" (which should be the ac3 equivalent to extracting a DTS core from a DTS-HD MA track) then eac3to says decoding with libav/ffmpeg and encoding AC3 <640kbps> with libAften, so the stream gets indeed reencoded. same with the same cmd line and "-core" in addtion.

edit: Ive found the .ec3 -core information, but it would be nice if this could be documented within eac3to as well.

edit²: why is it actually .ec3 -core here and not just .ac3 -core? that would make more sense compared to how it works with .dts

BigPines

31st January 2016, 17:24

Sadly, the PC I had eac3to perfectly set-up on and my backup drive were both destroyed in a single catastrophic event. :(

I am trying to put Humpty Dumpty back together and it is tough to say the least. I recall that years ago I spent days trying to get the perfect install of eac3to and all of it's dependencies but it has been so long, I can't recall everything necessary to get back there. This thread is so long now that I am having trouble finding up-to-date info on this. Could someone point me to the most relevant installation instructions for the best possible install of this wonderful tool and all it's dependencies? I am looking for which versions of the dependencies to use and how to install only what I need to make it work in the highest quality possible and nothing else. Thanks in advance!

Boulder

31st January 2016, 18:33

I think that what comes to decoding, currently you are fine with whatever is included in the eac3to package (apart from AAC decoding). Dcadec and libav will handle everything else except AAC, which apparently needs the Nero Directshow decoder.

What comes to encoding, I personally prefer to either decode to WAV and encode that in a separate encoder or pipe to the encoder directly.

BigPines

1st February 2016, 01:04

I only use the decoding. Looks like I need Nero for sure and probably ArcSoft too. Trying to get it going.

Boulder

1st February 2016, 04:45

You don't need ArcSoft at all, dcadec can handle everything it does.

BigPines

1st February 2016, 04:50

My understanding is Nero Lite will work but I have installed Nero Lite 7.11.10.0 and I still get the message that Nero Audio Decoder is not installed. I guess I'll try something else.

Sparktank

1st February 2016, 08:13

You could always pipe to QAAC. Something that still gets updates.

BigPines

1st February 2016, 19:44

I finally think I have eac3to going as best I can. I decided to get it going with as many features as possible since my prior install was fully functional. Again, my goal was to make as light an install as possible with the most features and the best components.

Seems like it has been a while since someone posted the steps for a complete install so I am posting this in the hopes it will save someone else some time. A couple of notes:

- I was unable to obtain Sonic Cinemaster Audio Decoder 4.3 so installation of that component is not covered below.
- I was unable to figure out how to register only the required library(s) for Haali Media Splitter so below describes a full install.
- I was unable to figure out how to register only the required library(s) for Nero so below describes a full install. I tried what is described in the following thread but I kept getting errors trying to regsvr32 the libraries so I gave up: http://forum.doom9.org/showthread.php?p=1396997#post1396997
- I was unable to figure out how to register only the required library(s) for SurCode DTS Encoder so below describes a full install.

If someone wants to help make this better and has information on how I can accomplish any of the shortfalls listed above, I am interested.

Setting Up eac3to on Windows 7 x64:

1) Download the latest eac3to from here: http://madshi.net/eac3to.zip

The link is also in the first post at the beginning of this thread.

2) Copy the eac3to directory to "C:\Program Files (x86)\"

3) Copy the necessary ArcSoft DLLs into the eac3to directory.

If you need these dlls, checkactivate.dll comes from ArcSoft TotalMedia Theater 2.x. The rest of the files come from ArcSoft TotalMedia Theater 6.x. Install ArcSoft TotalMedia Theater 6.x and harvest the DLLs from here:

C:\Program Files (x86)\ArcSoft\TotalMedia Theatre 6\MagCore.dll
C:\Program Files (x86)\ArcSoft\TotalMedia Theatre 6\MagPCMac.dll
C:\Program Files (x86)\ArcSoft\TotalMedia Theatre 6\MagUIEngine.dll
C:\Program Files (x86)\ArcSoft\TotalMedia Theatre 6\MagUIInter.dll
C:\Program Files (x86)\ArcSoft\TotalMedia Theatre 6\Codec\ASAudioHD.ax
C:\Program Files (x86)\ArcSoft\TotalMedia Theatre 6\Codec\DtsDec.dll
C:\Program Files (x86)\ArcSoft\TotalMedia Theatre 6\Codec\dtsdecoderdll.dll

Place the DLLs in the eac3to directory. Uninstall ArcSoft once you have the DLLs.

4) Run the following in the Command Prompt AS ADMINISTRATOR:

regsvr32.exe "C:\Program Files (x86)\eac3to\ASAudioHD.ax"

5) Copy neroAacEnc.exe into the eac3to directory.

If you need to get this, download free from: http://www.nero.com/eng/company/about-nero/nero-aac-codec.php. After unzipping, harvest the .exe from: \NeroAACCodec-1.5.1.zip\win32\neroAacEnc.exe

6) Install Haali Media Splitter. It can be downloaded free from: https://haali.su/mkv/

7) Install Surcode DVD Pro DTS Encoder v1.0.29

8) Install Nero 7.11.10.0 Micro/Lite

Go to Start->All Programs->Nero->Setup->Nero ProductSetup.

On the Left hand side click the Key icon which says License and enter the appropriate HD Audio serial numbers.

Snowknight26

1st February 2016, 19:51

Just because eac3to tells you that a component is missing doesn't mean it's required. The ArcSoft DTS decoder, for example, is essentially unneeded.

BigPines

1st February 2016, 23:09

Just because eac3to tells you that a component is missing doesn't mean it's required. The ArcSoft DTS decoder, for example, is essentially unneeded.

Unless you run into low bitrate or extension for secondary audio DTS streams. Why not configure it just in case?

Snowknight26

2nd February 2016, 00:21

Because the chances of that happening and you needing to convert it are so low that you'll spend more time getting eac3to to recognize every other program than necessary, but to each their own I guess.

BigPines

2nd February 2016, 02:36

Yes, for me it was worth it to deal with it once and never have to think about it again...hopefully anyway. ;)

Music Fan

2nd February 2016, 17:23

6) Install Haali Media Splitter
What is its utility with eac3to ? I never installed Haali Media Splitter.

BigPines

2nd February 2016, 17:45

Thunderbolt8

2nd February 2016, 19:10

Music Fan, it is for muxing into mkv container. Haali Media Splitter replaces the older Haali Matroska Muxer.

I am now running into a new problem I hadn't noticed before on my prior install. When converting a DTS-MA track to mono wavs, I get the following warning from libDcaDec: "XLL output not lossless". I found this post that seems to be related: http://sasshkas.blogspot.com/2015/11/dts-decoder-why-xll-streams-are-not.html

Are we sure libDcaDec is just as accurate as ArcSoft?maybe its related to this: https://github.com/foo86/dcadec/commit/4efd86974e4054aea69f09ec651a96efff05309e

perhaps not so much the reason why you get the message, but more so that it shouldnt matter regarding the quality of the track.

nevcairiel

2nd February 2016, 19:16

I am now running into a new problem I hadn't noticed before on my prior install. When converting a DTS-MA track to mono wavs, I get the following warning from libDcaDec: "XLL output not lossless". I found this post that seems to be related: http://sasshkas.blogspot.com/2015/11/dts-decoder-why-xll-streams-are-not.html

The message is normal, some streams just can't be decoded losslessly because they were mastered badly. The result is identical to other DTS decoders.

The post you found talks about something else entirely.

Are we sure libDcaDec is just as accurate as ArcSoft?

Yes.

BigPines

2nd February 2016, 20:24

Thanks. The message is a bit disconcerting. I wish I understood exactly what is happening but for now, I guess I'll just ignore it.

Now, every DTS-MA track I convert gives me this "XLL output not lossless" message. Does everyone else get this message every time too?

Nico8583

5th February 2016, 13:24

Is there a way to apply DRC with eac3to ? I've seen this option on BD Rebuilder but I know it doesn't use eac3to and I would like to test this feature without rebuild a Blu ray.
Thank you !

tebasuna51

5th February 2016, 19:07

Is there a way to apply DRC with eac3to?
Nope.

Apply DRC is intended to be used at play time, not at recode time.

If you want use the DRC included in AC3 streams when recode you can use BeHappy or the old BeSweet.

If you want apply something like DRC over any audio stream you can use Sox compand.

Nico8583

5th February 2016, 20:04

Nope.

Apply DRC is intended to be used at play time, not at recode time.

If you want use the DRC included in AC3 streams when recode you can use BeHappy or the old BeSweet.

If you want apply something like DRC over any audio stream you can use Sox compand.
Thank you, I would like to apply DRC when converting DTS to AC3 (or AC3 to AC3 if necessary to apply DRC) so I think I should go to BeHappy thread ? ;)

tebasuna51

5th February 2016, 21:50

I would like to apply DRC when converting DTS to AC3
DRC info in DTS is optional, and most the times don't exist.
Then you can obtain the same output decoding with or without apply DRC.

(or AC3 to AC3 if necessary to apply DRC)
Like I say you the DRC must be applied at play time.

Recode to AC3 don't have sense for me.

I can recommend only when you want downmix to stereo.
Then you can use BeHappy:
1) Load your AC3 source
2) Select NicAc3Source and Configure to "Down2, DRC"
3) Apply Normalize (100%)
4) Encode to AAC

EDIT: for more info use BeHappy thread

Nico8583

5th February 2016, 21:56

Thank you, but I want to keep 5.1 so I don't want to downmix to stereo. So I forget DRC, I will keep AC3 without recode and I will recode DTS to AC3 with eac3to or ffmpeg ;)
Thank you for the advise ;)

.sk

6th February 2016, 16:28

Is it possible to losslessly merge mp3 files (same encoder and settings) with eac3to into one mp3 file?

Thunderbolt8

6th February 2016, 17:02

dunno, but maybe it already works with "copy file1.mp3+file2.mp3+file3.mp3..."

tebasuna51

6th February 2016, 19:57

If you do:

copy /B file1.mp3 + file2.mp3 output.mp3
- some tags at end of file1.mp3 are at the midle of output.mp3
- If are VBR, the duration of output.mp3 show only the duration of file1.mp3.
And some players can stop play at this duration.

You can use eac3to:

eac3to file1.mp3+file2.mp3 output.mp3
- the tags at end of file1.mp3 are skiped
- The problem with VBR duration still exist.

You can use Foobar2000 and right click over the mp3 -> Utilities -> Fix VBR MP3 header

r0lZ

7th February 2016, 11:15

MP3DirectCut can also losslessly join two MP3 files (if they have been encoded exactly in the same way of course). You will have to copy the whole content of file 2, and paste it at the end of file 1, then save the complete audio. No problem with the tags or duration. Only the replay gain info (if any) may be wrong. And BTW, with the Copy /B trick (and perhaps also with eac3to), another problem exists. The bad samples at the end of the first file and beginnong of the second file are not removed, and a short silence may be perceptible. With MP3DirectCut, you cannot copy that part of the file (if it has been created with a good encoder), and there is no problem.

There are several versions of the MP3DirectCut program. I use the old one, still available here (http://filehippo.com/download_mp3directcut/). The new version is here (http://mpesch3.de1.cc/mp3dc.html). I don't remember why I have preferred the old version.

BTW, I've tried to remove one channel from a stereo MP3 without re-encoding, but I haven't found a tool to do it. It's useful when a mono track has been encoded in stereo, to regain disc space and be more coherent with the source. The two channels contain exactly the same data (or, with joint stereo, the second channel should be almost empty). Someone knows a tool able to do that?

LigH

7th February 2016, 11:26

Efficient MP3 encoders use Joint Stereo for audio which has probably similar channels, and use adaptively the Mid/Side encoding (not encoding the left channel separately from the right channel, but instead their sum and their difference, because the difference is probably rather low in comparison to the sum and thus needs less bitrate). What has not been encoded separately, cannot be separated without recoding.

r0lZ

8th February 2016, 10:43

That makes sense. Thanks.

Stereodude

8th February 2016, 19:54

What is its utility with eac3to ? I never installed Haali Media Splitter.
My understanding is that it's necessary if you want to have eac3to write directly to a MKV container.

Stereodude

8th February 2016, 19:58

You could always pipe to QAAC. Something that still gets updates.
I found this to be very slow. I'm not sure why and I didn't spend much time trying to figure out why. I had better luck dumping to an intermediate wave file and then encoding that with QAAC called via foobar. Despite two steps the latter was definitely faster.

fijam

11th February 2016, 13:40

Are there plans to update eac3to to use ffmpeg's ac3 encoder instead of the long-abandoned libaften?

tebasuna51

11th February 2016, 18:38

Are there plans to update eac3to to use ffmpeg's ac3 encoder instead of the long-abandoned libaften?

Only madshi can answer that question.
BTW you can use for instance:

eac3to INPUT stdout.w64 | ffmpeg -i - -c:a ac3 -b:a 640k -center_mixlev 0.707 - OUTPUT.ac3

73ChargerFan

13th February 2016, 09:47

eac3to INPUT stdout.w64 | ffmpeg -i - -c:a ac3 -b:a 640k -center_mixlev 0.707 - OUTPUT.ac3
That should be memorialized in the first post.

tebasuna51

13th February 2016, 14:06

That should be memorialized in the first post.

Done. You can check if there are enough info.

Trizep

14th February 2016, 21:37

How can I deactivate libdcadec.dll in eac3to?

I prefer Arcsoft decoder.

:thanks:

Q-the-STORM

15th February 2016, 18:39

How can I deactivate libdcadec.dll in eac3to?

I prefer Arcsoft decoder.

:thanks:

you can force any decoder with -decodername... nero, arcsoft, sonic etc...

so just do e.g.
eac3to input.dtsma output.flac -arcsoft

Trizep

15th February 2016, 18:53

:thanks:

And in MeGUI ?

LigH

15th February 2016, 19:04

If MeGUI does not support custom parameters in its own dialogs, then feed your project with a prepared intermediate result. Converter GUIs are made to support the most probable cases. Support for unusual cases is nice but not mandatory.

heerschop

15th February 2016, 21:50

:thanks:

And in MeGUI ?

In Megui you can use the HD streams extractor to convert a DTS stream. MeGui uses eac3to to do the conversion. In the column "+options" you can add extra commands for eac3to. Double click in "+options column" for the given dts stream and add -arcsoft in the column. Now eac3to uses acrsoft decoder instead of the default decoder.

73ChargerFan

15th February 2016, 21:51

Done. You can check if there are enough info.
Impressive, thanks.

Trizep

16th February 2016, 16:01

:goodpost:

But I´ve to insert the +option each time?
There is no possibility to save the -arcsoft option?

(For the first I´ve copied eac3to 3.28 in MeGUI)

LigH

16th February 2016, 16:15

This is rather a question about how to use MeGUI, instead of how to use eac3to ... in contrast to encoder dialogs, the HD Stream Extractor has no preset management.

torturesauce

17th February 2016, 18:36

We have dcadec on foobar again! ^^

Rollinnn

22nd February 2016, 10:39

Hello!
It seems there is little problem with decoding DTS-HD MA. Resulted file has some offset in audio data.
How I tested this: source wav was encoded to DTS-HD MA using DTS-HD Master Audio Suite Encoder, then dtshd file decodec using eac3to (with libdcadec.dll from dcadec 0.2.0 github release), and resulted wav compared to original wav using binary comparator in foobar2000.
This problem not appears when dtshd is decoded with dcadec.exe.
Is this eac3to fault or libdcadec.dll fault?
Attached samples: source flac and dtshd created with DTS-HD Master Audio Suite Encoder.
Source (flac) (https://www.dropbox.com/s/he3mvbweik8oyss/source.flac?dl=0) , DTHS-HD MA (https://www.dropbox.com/s/nuq09kw39jsi0zd/DTSENC.dtshd?dl=0)

nevcairiel

22nd February 2016, 11:16

Thats probably the padding added by the DTS-HD Master Audio Suite. The audio is still bit-perfect, there is just a little more of it.

Rollinnn

22nd February 2016, 11:37

Thats probably the padding added by the DTS-HD Master Audio Suite.
But decoding with dcadec.exe gives file identical to source without any offset.

tebasuna51

22nd February 2016, 12:38

Thats probably the padding added by the DTS-HD Master Audio Suite. The audio is still bit-perfect, there is just a little more of it.

Yep. There are 2 extra silence frames at begining. After cut the first 21.333 ms the output is bit-perfect.

Flac file length: 8.757s
DTS decoded file length: 8.789s
Like the DTS have 824 frames the DTS output file length is correct.

But decoding with dcadec.exe gives file identical to source without any offset.

Please suply a link to the windows binary dcadec.exe used.

I decoded the dts with ffmpeg, LWlibavsource and eac3to-ArcSoft with identical output than eac3to-dcadec.

Rollinnn

22nd February 2016, 12:55

Please suply a link to the windows binary dcadec.exe used.
Official release from foo86 on github - https://github.com/foo86/dcadec/releases/download/v0.2.0/dcadec-0.2.0-win32.zip

nevcairiel

22nd February 2016, 13:25

The dtshd file format written by the DTS-HD Master Suite has some metadata that instructs the decoder to cut off a few frames at the beginning. dcadec probably respects that while others do not. This isn't really the case for any other DTS-HD stream, as a stream extracted from a Blu-ray, for example, would never have such metadata.

tebasuna51

22nd February 2016, 13:26

Using:

dcadec -S DTSENC.dtshd outS.wav

(-S Don't strip padding samples for streams within DTS-HD container.)
the output is bit-identical to eac3to output.

But using the default:

dcadec DTSENC.dtshd out_.wav

the output is bit-identical to source without delay.
Seems than dcadec.exe use the delay info in initial global header of DTSENC.dtshd (recently encoded by Master Audio Suite)

Is good to know that, but is useless with standard dtshd extracted from a container.

Rollinnn

22nd February 2016, 13:46

The dtshd file format written by the DTS-HD Master Suite has some metadata that instructs the decoder to cut off a few frames at the beginning. dcadec probably respects that while others do not.
Thanks. So this is eac3to or libdcadec.dll itself, who doesn't respect this data?

nevcairiel

22nd February 2016, 13:48

Thanks. So this is eac3to or libdcadec.dll itself, who doesn't respect this data?

eac3to in this case. But like tebasuna51 and myself said, its largely unimportant with real world data from actual discs.

marcusj0015

27th February 2016, 18:20

@madshi It would be AMAZING if you would add a trimming feature that didn't silently drop the MVC sub-stream (unlike FFmpeg).

I'd do it myself, but I'm currently working on a DTS Express decoder for DCADec.

Thunderbolt8

28th February 2016, 16:23

does anyone know if eac3to would recognize UHD BDs and their streams correctly? if not and if anyone has a readable disc with their drive, maybe these folks can cut samples.

sneaker_ger

28th February 2016, 17:17

UltraHD BluRay comes with a new copy protection that is yet to be cracked so there is no way to cut any samples or test with eac3to.

Also: I believe eac3to does not handle HEVC (codec used for 4k video on BluRay) video at all, irregardless of the container.

hubblec4

3rd March 2016, 18:33

Hi madshi

I use eac3to for a very long time, but this is the first time that eac3to don't recognize all mpls exactly.

eac3to v3.31
command line: "D:\eac3to.exe" "I:\"
------------------------------------------------------------------------------
1) 00027.mpls, 3:47:47
[0+1+2+3+4+64].m2ts
- Chapters, 35 chapters
- h264/AVC, 1080p24 /1.001 (16:9)
- DTS Master Audio, English, multi-channel, 48kHz
- AC3, English, stereo, 48kHz
- AC3, German, stereo, 48kHz
- AC3, Spanish, stereo, 48kHz
- AC3, French, stereo, 48kHz
- AC3, Italian, stereo, 48kHz
- AC3, Japanese, stereo, 48kHz

2) 00040.mpls, 00000.m2ts+00064.m2ts, 0:45:36
- Chapters, 7 chapters
- h264/AVC, 1080p24 /1.001 (16:9)
- DTS Master Audio, English, multi-channel, 48kHz
- AC3, English, stereo, 48kHz
- AC3, German, stereo, 48kHz
- AC3, Spanish, stereo, 48kHz
- AC3, French, stereo, 48kHz
- AC3, Italian, stereo, 48kHz
- AC3, Japanese, stereo, 48kHz

3) 00041.mpls, 00001.m2ts+00064.m2ts, 0:45:35
- Chapters, 7 chapters
- h264/AVC, 1080p24 /1.001 (16:9)
- DTS Master Audio, English, multi-channel, 48kHz
- AC3, English, stereo, 48kHz
- AC3, German, stereo, 48kHz
- AC3, Spanish, stereo, 48kHz
- AC3, French, stereo, 48kHz
- AC3, Italian, stereo, 48kHz
- AC3, Japanese, stereo, 48kHz

4) 00031.mpls, 00003.m2ts+00064.m2ts, 0:45:34
- Chapters, 7 chapters
- h264/AVC, 1080p24 /1.001 (16:9)
- DTS Master Audio, English, multi-channel, 48kHz
- AC3, English, stereo, 48kHz
- AC3, German, stereo, 48kHz
- AC3, Spanish, stereo, 48kHz
- AC3, French, stereo, 48kHz
- AC3, Italian, stereo, 48kHz
- AC3, Japanese, stereo, 48kHz

5) 00042.mpls, 00002.m2ts+00064.m2ts, 0:45:33
- Chapters, 7 chapters
- h264/AVC, 1080p24 /1.001 (16:9)
- DTS Master Audio, English, multi-channel, 48kHz
- AC3, English, stereo, 48kHz
- AC3, German, stereo, 48kHz
- AC3, Spanish, stereo, 48kHz
- AC3, French, stereo, 48kHz
- AC3, Italian, stereo, 48kHz
- AC3, Japanese, stereo, 48kHz

6) 00044.mpls, 00004.m2ts+00064.m2ts, 0:45:32
- Chapters, 7 chapters
- h264/AVC, 1080p24 /1.001 (16:9)
- DTS Master Audio, English, multi-channel, 48kHz
- AC3, English, stereo, 48kHz
- AC3, German, stereo, 48kHz
- AC3, Spanish, stereo, 48kHz
- AC3, French, stereo, 48kHz
- AC3, Italian, stereo, 48kHz
- AC3, Japanese, stereo, 48kHz

The mpls 00043 is not shown, but it is a normal episode like mpls 00044 or 00042.

Stereodude

3rd March 2016, 20:54

You can manually feed it 00043.mpls from the command line though, so is that really a problem?

73ChargerFan

3rd March 2016, 21:38

Caerbannog

3rd March 2016, 21:58

Sparktank

3rd March 2016, 22:59

Is there a workaround or fix that can be applied to fix this?

Try a different decrypter.
What did you use to decrypt? Try updating whatever it is.
MakeMKV updated recently to v1.9.9.

Clean the disc and/or drive lense?

Stereodude

3rd March 2016, 23:02

hubblec4,
To make matters worse, there is a copy protection scheme for movie blu-rays where the MPLS files are a bit scrambled, and there's hundreds of them, so it becomes difficult to find the correct MPLS for what you're looking for. When in doubt, I use MPC-BE to watch the playlist and confirm it is correct before taking the time to demux.
AnyDVD HD handles this. The .inf file it injects into the root folder of the disc tells you which playlist to use (if it had playlist obfuscation).

Caerbannog

4th March 2016, 00:01

Try a different decrypter.
What did you use to decrypt? Try updating whatever it is.
MakeMKV updated recently to v1.9.9.

Clean the disc and/or drive lense?

This doesn't appear to be an issue with the image but rather a case of how the subtitles are on the disc. Unfortunately, Avatar has forced subtitles, so without them some scenes won't make sense. This was originally reported in 2013 but appears to still be a problem. The bug that refers to this is http://bugs.madshi.net/view.php?id=87 but I was hoping that there was a workaround for the time being.

Q-the-STORM

4th March 2016, 00:19

Hi madshi

I use eac3to for a very long time, but this is the first time that eac3to don't recognize all mpls exactly.
[...]
The mpls 00043 is not shown, but it is a normal episode like mpls 00044 or 00042.
I am very sure 00043.mpls is a duplicate of 00031.mpls...

00027.mpls contains all 5 episodes 00000.m2ts, 00001.m2ts, 00002.m2ts, 00003.m2ts and 00004.m2ts....

eac3to is showing 5 additional playlists:
00040.mpls contains 00000.m2ts
00041.mpls contains 00001.m2ts
00042.mpls contains 00002.m2ts
00031.mpls contains 00003.m2ts
00044.mpls contains 00004.m2ts

all episodes are present...
it is not unusual for BDs to have duplicate playlists, it just happens to be that eac3to picked 31 instead of 43... but the m2ts files they contain should be exactly the same...

r0lZ

4th March 2016, 10:06

Apparently, the Avatar (James Cameron) 3D Blu-ray is still getting hit with the "the source file seems to be damaged" error when attempting to work on the first English subtitle stream. Is there a workaround or fix that can be applied to fix this? This is the first of all of my 3D BDs to have this issue. (I'm not a newbie, but I've never dealt with extracting individual streams if that's what it takes.) I'm currently using BDtoAVCHD v2.5.3.
It's a known bug of eac3to with some 3D-BDs.

In 3D BDs, the 3D movie is contained in 2 different M2TS files and one SSIF file at the same time. A M2TS contains the AVC video stream and all audio and subtitle streams. It's the M2TS that is referenced by the 2D playlist, and that is strictly compatible with the old 2D-only BD players. Another M2TS contains only the dependent (MVC) video stream, no audio and usually no subtitle stream. It is useless, since the MVC stream cannot be decoded without the AVC stream. The two M2TS are merged to form the SSIF file when the disc is mastered (or the ISO created). The SSIF contains therefore the two video streams, all audio streams, and all subtitle streams. It's the SSIF that is referenced by the 3D MPLS and decoded and played by a 3D BD player.

The problem is that sometimes (and notably in Avatar 3D), the second M2TS contains also the subtitle streams. (I have never understood why, but it's relatively frequent.) That subtitles have EXACTLY the same stream IDs that their equivalent in the first M2TS. Therefore, the final SSIF contains two times the same subtitle streams. And eac3to gets confused, because it tries to extract the two subtitle streams with the same ID from the SSIF as a single, unique stream. Of course, that causes timings conflicts, and it issues numerous error messages.

There is currently no solution, except to extract the subtitles from the first M2TS instead of the SSIF. You have to find the corresponding 2D MPLS to force eac3to to use the 2D M2TS. Unfortunately, not all 3D-BDs have a 2D MPLS. (I don't remember for Avatar.) And anyway, eac3to will probably hide it from its list of MPLS files, because it will consider the 2D MPLS as a duplicate of the 3D one, and remove it from the list.

The other solution is to use the relatively recent 3D version of tsMuxeR to demux the 3D MPLS. It handles the double subtitle streams well. (But take care anyway. It has other bugs. Personally, I use ONLY tsMuxeR v2.6.9. It seems that it's the only version that has no problems with the timings of some subtitle streams. It's that version that is distributed with BD3D2MK3D.)

hubblec4

4th March 2016, 10:07

@ Q-the-STORM

You are right, mpls 00031 seems to be the same like 00043.

Caerbannog

4th March 2016, 16:47

There is currently no solution, except to extract the subtitles from the first M2TS instead of the SSIF. You have to find the corresponding 2D MPLS to force eac3to to use the 2D M2TS. Unfortunately, not all 3D-BDs have a 2D MPLS. (I don't remember for Avatar.) And anyway, eac3to will probably hide it from its list of MPLS files, because it will consider the 2D MPLS as a duplicate of the 3D one, and remove it from the list.

The other solution is to use the relatively recent 3D version of tsMuxeR to demux the 3D MPLS. It handles the double subtitle streams well. (But take care anyway. It has other bugs. Personally, I use ONLY tsMuxeR v2.6.9. It seems that it's the only version that has no problems with the timings of some subtitle streams. It's that version that is distributed with BD3D2MK3D.)Ugh. I was hoping that after three years it would have been fixed, but I understand why it's not a priority if it only affects a handful of 3DBDs.

I doubt that there is anything 2D related with this. My disc is one of the Panasonic exclusives that they were distributing with their initial 3D Blu-ray players. Looks like I'll have to go out of my comfort zone to figure this out, but that's not necessarily a bad thing.

73ChargerFan

4th March 2016, 21:15

Another solution is to download a SRT version of the subtitle track.

r0lZ

5th March 2016, 11:26

SRT is not in 3D.

bmcelvan

11th March 2016, 14:44

Two quick questions.

Is there any point to using Arcsoft anymore when decoding DTS-HD MA of any kind, the libDcaDec seems to work for all, am I wrong?

Secondly, when using eac3tov3.31 when decoding DTS-HD MA 7.1, I get an error "libDcaDec reported the warning "XLL output not lossless"" and when using Arcsoft I get the message "volume will be low". If I simply use eac3tov3.30 without Arcsoft, I get no errors reported at all.

Any ideas?

Thanks Ben

tebasuna51

11th March 2016, 15:58

Is there any point to using Arcsoft anymore when decoding DTS-HD MA of any kind, the libDcaDec seems to work for all, am I wrong?
Arcsoft is necessary for DTS-Express only, BTW remain like a option for users than prefer it.

...when decoding DTS-HD MA 7.1, I get an error "libDcaDec reported the warning "XLL output not lossless""
Don't worry about that. Maybe are frames than not need lossless subframes (XLL), for instance silent frames.

...and when using Arcsoft I get the message "volume will be low"
Only when DTS-MA is "strange setup" ArcSoft remix the output channels forcing to have less volume than original. libDcaDec don't remix the channels.

Atak_Snajpera

16th March 2016, 15:09

I must say that built-in flac encoder could be faster. This method is about 2.5x faster than regular command.

eac3to.exe drive_video_10min.mkv 2:stdout.wav | CUETools.FLACCL.cmd.exe --ignore-chunk-sizes --opencl-type CPU --opencl-platform "Intel(R) OpenCL" -o c:\temp\audio.flac -

10min 5.1 DTSMA -> 5.1 FLAC
CPU: Xeon E5-2690 @ 2.9 GHz (8C/16T)
eac3to Built-in encoder : 64s (Encoder+Decoder CPU usage: 7%)
FlacCL (Intel Platform) : 26s (Decoder CPU usage: 7% , Encoder CPU usage: 5%)
FlacCL (AMD platform) : 115s (Decoder CPU usage: 2% , Encoder CPU usage: 67%)

Regarding Intel Platform. It clearly shows that decoder is a bottleneck here because 7% means full single core utilization.
I'm really disappointed with AMD platform. Despite nice multi-threading encoding is very slow.

Sparktank

16th March 2016, 17:48

FLAC library is replacable, in case of updates.

It's just limited to whoever compiles it out there.
RareWares will use ICL over GCC.

You have to scour the HydrodgenAudio forum for different builds.

OpenCL would vary too much from person to person to make it a default.
I've always used FLACCL as an external encoder after using eac3to. Doing other things with the audio first, so never piped directly to FLACCL.
In other instances, it wasn't time critical to wait for ICL FLAC to do its work.

My only options would be:
ICL FLAC
Intel FLACCL
NVidia FLACCL

order

21st March 2016, 08:20

anybody help me. When I demux atmos on windows 10 pro to mono wavs. I get error. I installed avisynth 2.6, arsoft decoder 1.4, eac3to 3.31, Klite codec. Tks. But when demux to ths+ac3 and thd. It's ok.

http://t1.someimage.com/G1bon34.jpg (https://someimage.com/G1bon34)

LigH

21st March 2016, 09:11

And which error?

order

21st March 2016, 09:41

And which error?
Can not demux. Fail

tebasuna51

21st March 2016, 10:34

When I demux atmos on windows 10 pro to mono wavs. I get error. I installed avisynth 2.6, arsoft decoder 1.4, eac3to 3.31, Klite codec. Tks. But when demux to ths+ac3 and thd. It's ok.

Is not related with AviSynth, Arsoft or other codec.
And you have the last eac3to version.

- Try to work with the extracted .thd file:

eac3to extracted.thd mono.wavs

If you have the same error "restart header sync incorrect" maybe is a corrupt file or a bug in libav decoder.

- You can also try with other decoder like:

ffmpeg extracted.thd output.w64

Or load the extracted.thd in MeGUI Audio Input and select Flac like Encoder settings, config -> Preferred decoder LWLibavAudioSource.

order

22nd March 2016, 03:07

Is not related with AviSynth, Arsoft or other codec.
And you have the last eac3to version.

- Try to work with the extracted .thd file:

eac3to extracted.thd mono.wavs

If you have the same error "restart header sync incorrect" maybe is a corrupt file or a bug in libav decoder.

- You can also try with other decoder like:

ffmpeg extracted.thd output.w64

Or load the extracted.thd in MeGUI Audio Input and select Flac like Encoder settings, config -> Preferred decoder LWLibavAudioSource.
I've try but not success. I don't know reason why?
http://i.imgur.com/8MQkwOX.png

I'm using cmd to test wil be fine:

http://i.imgur.com/Bzsz1dO.png

Bandits

22nd March 2016, 03:39

Is there a command/option to show all tracks on a disc not just the longer ones?

I am trying to load tracks that are only 5 minutes in length and they are not detected. I also require to find them from a disc not a mpls or m2ts.

eac3to v3.31
command line: "C:\eac3to\eac3to.exe" "E:" -log="C:\eac3to\1stpass.txt"
------------------------------------------------------------------------------
HD DVD / Blu-Ray disc structure not found. <ERROR>

tebasuna51

22nd March 2016, 10:23

I've try but not success. I don't know reason why?

Like I say before:
is a corrupt file or a bug in libav decoder.

Try other decoder (ffmpeg, LWLibavAudioSource) or rerip the BD.

tebasuna51

22nd March 2016, 10:24

Is there a command/option to show all tracks on a disc not just the longer ones?

Nope, sorry.

cyanide1l

23rd March 2016, 02:31

r0lZ

23rd March 2016, 08:51

Use BDSup2Sub (Edit frame -> Exclude from export).

mbcd

23rd March 2016, 18:03

Hello,

i have a problem extracting subtitles. Well it works all fine, but the last subtitle is always "[GERMAN]". How does that come? Tried that with more movies and its the same everywhere. So at the end of the movie i always see "[GERMAN]" on my screen. I tried to delete it with SubtitleEdit, but it seems like i cant save it as .sup again. i dont want .srt. And if i export to .sup, it removes the shadow behind my font.

What i used to extract the Stream:

eac3to and HdBrStreamExtractor.

Hope you can help.

Here is a Screen of it: http://fs5.directupload.net/images/160323/vxjnmfv5.png

That is normal, the company which wrote these subtitles put that in. Every company adds their own endwords. Some write also "Untertitel von Ute Schmidt", or simple "Untertitel: Visiontext". It is not an errror or fault from eac3to. You have to delete these lines by hand.

Overdrive80

27th March 2016, 15:31

Hi, I am converting one audio from eac3to to ffmpeg using pipe way, but I get this message of ffmpeg I dont know its meaning.

ffmpeg version N-79143-g8ff0f6a Copyright (c) 2000-2016 the FFmpeg developers
built with gcc 5.3.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-libmfx --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libschroedinger --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable-libzimg --enable-lzma --enable-decklink --enable-zlib
libavutil 55. 19.100 / 55. 19.100
libavcodec 57. 30.100 / 57. 30.100
libavformat 57. 29.101 / 57. 29.101
libavdevice 57. 0.101 / 57. 0.101
libavfilter 6. 40.102 / 6. 40.102
libswscale 4. 0.100 / 4. 0.100
libswresample 2. 0.101 / 2. 0.101
libpostproc 54. 0.100 / 54. 0.100
Input #0, w64, from 'pipe:':
Duration: N/A, bitrate: 2304 kb/s
Stream #0:0: Audio: pcm_s24le ([1][0][0][0] / 0x0001), 48000 Hz, stereo, s32 (24 bit), 2304 kb/s
Output #0, ac3, to 'D:\Peli 3\AudioFile_80_mod.ac3':
Metadata:
encoder : Lavf57.29.101
Stream #0:0: Audio: ac3, 48000 Hz, stereo, fltp (24 bit), 384 kb/s
Metadata:
encoder : Lavc57.30.100 ac3
Stream mapping:
Stream #0:0 -> #0:0 (pcm_s24le (native) -> ac3 (native))
Multiple frames in a packet from stream 0 384.0kbits/s speed= 98x
[pcm_s24le @ 000001e428e2d900] Invalid PCM packet, data has size 4 but at least a size of 6 was expected
Error while decoding stream #0:0: Invalid data found when processing input
size= 164242kB time=00:58:23.83 bitrate= 384.0kbits/s speed=95.6x
video:0kB audio:164242kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.000000%

Commandline used:

@echo off

set "rea=C:\Portables\UsEac3to\eac3to\"
set "rff=C:\Portables\UsEac3to\Tools\"

"%rea%eac3to" %1 stdout.w64 -progressnumbers -speedup -normalize | "%rff%ffmpeg" -y -i - -c:a ac3 -b:a 384k "%~dpn1_mod.ac3"

Any idea? Thanks.

EDIT: With "%rea%eac3to" %1 stdout.w64 -progressnumbers -speedup -normalize -down32 | "%rff%ffmpeg" -y -i - -c:a ac3 -b:a 384k "%~dpn1_mod.ac3"
Message doesnt show.

tebasuna51

27th March 2016, 16:06

Hi, I am converting one audio from eac3to to ffmpeg using pipe way, but I get this message of ffmpeg I dont know its meaning.

If your eac3to version is less than 3.30 update to v3.31

Overdrive80

28th March 2016, 12:15

@Tebasuna51, the version of eac3to when I get that message was current version.

tebasuna51

28th March 2016, 18:38

This problem occurs before v3.30 when eac3to try to close the w64 file to write the correct header, but I don't know for what occurs with v3.31.
I can't reproduce the problem with the same command line.

Each block of PCM 2.0 24 bits must be 6 bytes, if ffmpeg only receive 4 there are 2 bytes missing at least.

lvqcl

28th March 2016, 21:33

Each block of PCM 2.0 24 bits must be 6 bytes, if ffmpeg only receive 4 there are 2 bytes missing at least.

Maybe eac3to writes padding bytes to the end of audio data?

From .w64 spec pdf: "All chunks are byte-aligned on 8-byte boundaries"

asarian

28th March 2016, 23:21

Just did a clean install of windows 10:

eac3to (v3.31) is up to date
Nero Audio Decoder (Nero 6 or older) doesn't seem to be installed
http://www.nero.com/eng/store-blu-ray.html
CAUTION: You need Nero 7. Nero 8 won't work with eac3to.
ArcSoft DTS Decoder (1.1.0.0) works fine
Sonic Audio Decoder (3.31.0.0) doesn't seem to be installed
Haali Matroska Muxer doesn't seem to be installed
http://haali.net/mkv
Nero AAC Encoder (1.5.4.0) is installed
Surcode DTS Encoder doesn't seem to be installed
http://www.surcode.com

However, when I try to demux my DTS-MA audio, I get:

a03 Extracting audio track number 3...
a03 Decoding with libDcaDec DTS Decoder...
a03 libDcaDec reported the warning "XLL output not lossless".
a03 Mixing surround channels...

I dont want the libDcaDec DTS Decoder, though, but my Arcsoft one (used to work on Win 7 just fine); and eac3to, with the registered Arcsoft dll, is in the path. Did I miss a step somewhere?! Thanks.

Boulder

29th March 2016, 03:48

You have to specify -arcsoft in the command line. LibDcaDec is used by default and it is installed along with eac3to.

Sparktank

29th March 2016, 05:47

a03 libDcaDec reported the warning "XLL output not lossless"

it that's the only concern, dts decoding was like that before with earlier implementation of dcadec.
Just silently.

Arcsoft, too, iirc from earlier posts.
All just silent warnings.

dcadec is nice. you only need one version for most formats.
(minus express)

with Arcsoft, when it comes to "strange setup", it's a gambler's game on which version works on what source.

asarian

29th March 2016, 07:57

it that's the only concern, dts decoding was like that before with earlier implementation of dcadec.
Just silently.

Arcsoft, too, iirc from earlier posts.
All just silent warnings.

dcadec is nice. you only need one version for most formats.
(minus express)

with Arcsoft, when it comes to "strange setup", it's a gambler's game on which version works on what source.

Thx. :) Guess I can just keep using libDcaDec then. Indeed, the occasional 'strange setup' and low volume issues that came with the Arcsoft decoder are something I could do without.

bmcelvan

29th March 2016, 14:12

Arcsoft is necessary for DTS-Express only, BTW remain like a option for users than prefer it.

Don't worry about that. Maybe are frames than not need lossless subframes (XLL), for instance silent frames.

Only when DTS-MA is "strange setup" ArcSoft remix the output channels forcing to have less volume than original. libDcaDec don't remix the channels.

Thanks for this reply, very helpful. MY interpretation of this means that eac3to v3.30 probably has that XLL error as well, it just didn't mention it? ...and with that said, I assume your advice is to ALWAYS USE THE MOST CURRENT VERSION OF EAC3TO? So currently 3.31.

Next question, just to verify, the current version 3.31 can properly decode TrueHD-Atmos to .wavs or convert to .flac? Iv'e been getting the "libav Lossless check failed" errors. From reading through the posts it appears that more than likely I have a corrupted file. Or are there still instances where eac3to won't decode Atmos properly?

In either case I should try ffmeg?

Thanks again

Boulder

29th March 2016, 16:11

asarian

29th March 2016, 17:10

bmcelvan

30th March 2016, 18:38

Are those "lossless check failed" files from movies that are constructed of multiple m2ts files? I've noticed that it occurs at the beginning of each segment, but there is nothing audible there despite the error message.

Doesn't appear to be for me. I can't explain it, I just re-downloaded v3.31. Ripped via DVDfab to BDMV folder on my HDD the Bluray "Brave" and it simply won't extract the truehd file to .wavs or .flac or anything without giving the lossless check failed errors. Even at 17%, so that's a good chunk of the way thru the movie, not at the beginning.

Could this have anything to do with the TrueHD audio dropouts reported on a bunch of websites for Pixar titles like Monsters University, Brave, Total Recall (2011), etc. Apparently, bluray players needed to be set to LCPM output instead of bitstreaming to fix the problem?

Snowknight26

30th March 2016, 22:53

The lossless check failed errors are normal for Blu-rays that use seamless branching. eac3to has no problems with them as of 3.25, released over 3 years ago.

bmcelvan

31st March 2016, 13:57

The lossless check failed errors are normal for Blu-rays that use seamless branching. eac3to has no problems with them as of 3.25, released over 3 years ago.

Thanks for reply...two quick questions then.

Seamless branching means that if you look at the .mpls file it will have multiple m2ts files that it looks at? For example after eac3to has looked at a title you might see something like: 00800.mpls, 00001.m2ts+00005.m2ts+00670.m2ts, etc??

Second question: decoding/converting atmos is now not a problem for eac3to either, right? That was solved in version 3.28?

thx

bmcelvan

31st March 2016, 14:06

Quick question about this past conversation...every single one of the "lossless check failed" errors only represents 1 byte?

Also, could it ever mess up the alignment of the audio track...I mean shorten it or lengthen it slightly, or would it simply be just added (or deleted) sounds but not affect it's length?

Done, but still getting errors. This track is definitely skunked.

[truehd @ 024c0900] Lossless check failed - expected 4f, calculated 53.
[truehd @ 024c0900] mlpparse: Parity check failed.
[truehd @ 024c0900] Lossless check failed - expected 33, calculated 83.
[truehd @ 024c0900] mlpparse: Parity check failed.
[truehd @ 024c0900] Lossless check failed - expected 9d, calculated 72.
[truehd @ 024c0900] mlpparse: Parity check failed.
[truehd @ 024c0900] Lossless check failed - expected b2, calculated 41.
[truehd @ 024c0900] Invalid nonrestart_substr.
Error while decoding stream #0:0: Invalid data found when processing input
[truehd @ 024c0900] Stream parameters not seen; skipping frame.
Last message repeated 32 times
[truehd @ 024c0900] mlpparse: Parity check failed.
[truehd @ 024c0900] Lossless check failed - expected da, calculated 77.
[truehd @ 024c0900] mlpparse: Parity check failed.
[truehd @ 024c0900] Lossless check failed - expected f0, calculated 3f.
[truehd @ 024c0900] mlpparse: Parity check failed.

Most likely because the source uses seamless branching. Only 6 bytes of probably over 3GB is corrupt. You won't even hear it.

LigH

31st March 2016, 14:13

Second question: decoding/converting atmos is now not a problem for eac3to either, right? That was solved in version 3.28?

thx

Dolby Atmos metadata should reliably be ignored in current versions.

tebasuna51

31st March 2016, 19:57

Seamless branching means that if you look at the .mpls file it will have multiple m2ts files that it looks at? For example after eac3to has looked at a title you might see something like: 00800.mpls, 00001.m2ts+00005.m2ts+00670.m2ts, etc??

Yes.

To know more about extracting/decoding audio from seamless branching BD's you can see: http://forum.doom9.org/showthread.php?p=1600694#post1600694

eac3to try to solve the problems but not always is possible.

asarian

31st March 2016, 20:11

Dolby Atmos metadata should reliably be ignored in current versions.

Brilliant! :) It was a PITA doing the conversion manually!

bmcelvan

1st April 2016, 20:52

Yes.

To know more about extracting/decoding audio from seamless branching BD's you can see: http://forum.doom9.org/showthread.php?p=1600694#post1600694

eac3to try to solve the problems but not always is possible.

Thanks for that thread...very helpful inunderstanding what is happening, thank you.

Is there a simple answer to my earlier question about what each lossless check failed means in terms of added or reduced audio track duration? Or is every occurrence potentially different ? (and saying something like "each error adds 1/32 seconds time to the track" just doesn't make sense)

tebasuna51

1st April 2016, 21:44

Is there a simple answer to my earlier question about what each lossless check failed means in terms of added or reduced audio track duration?

A frame bad initialized can produce glitches like here (http://forum.doom9.org/showthread.php?p=1587184#post1587184) but don't change duration.

r4dius

4th April 2016, 20:38

Could you show info about "forced" subtitles (at leat with mkv files) ?

And btw thanks for one of the best ripping tools ever :)

Stereodude

4th April 2016, 22:26

Are those "lossless check failed" files from movies that are constructed of multiple m2ts files?
In that case it has to deal with floating point math and integer math so it's not exactly lossless.

"The main problem is that the core decoder converts integer coefficients read from the bitstream to floats just after reading them (along with dequantization). All other steps of the audio reconstruction are done with floats and the output can not be the bitexact reproduction of the input so it is not lossless."

From http://sasshkas.blogspot.com/2015/11/dts-decoder-why-xll-streams-are-not.html

bmcelvan

5th April 2016, 16:32

A frame bad initialized can produce glitches like here (http://forum.doom9.org/showthread.php?p=1587184#post1587184) but don't change duration.

Okay, so occasionally there may be some sort of (glitch) noise that you could hear (but probably can't hear it) but it won't affect the audio track aligning properly with the rest of the movie (from that glitch point on)?

bmcelvan

13th April 2016, 19:17

I just want to make sure I'm not the only one, I've encoded audio for 10 movies in the last 2 weeks or so and with v331 and DTS-HD MA tracks I get the error (a03 libDcaDec reported the warning "XLL output not lossless") EVERY SINGLE TIME!!!

Is everyone else getting this error every single time?

I understand people are telling me "don't worry about" but if it isn't something to worry about why does it pop up every time and/or why hasn't it been hidden?

For all those same movies, as stated before, v330 it doesn't appear.

Lastly, what are the reasons to use 331 over 330?

thx

Sparktank

13th April 2016, 20:07

why does it pop up every time and/or why hasn't it been hidden?

It was hidden in the versions that don't show it.
v330 has the same warnings but it just doesn't tell you about it.

Reasons to use 331 over 330?
Some of the udpates might be relevant in certain circumstanes.
* libDcaDec: updated to latest build
* libDcaDec: decoding only aborts on critical issues now
* libDcaDec: now reports warnings if something isn't 100% perfect
* libDcaDec: proper handling of clipped files (2nd pass etc)
* libDcaDec: proper handling of tracks that switch bitdepth 16 <-> 24
* fixed: TrueHD decoding -> AC3 encoding didn't work properly

As tebasuna51 mentioned before...
Don't worry about that. Maybe are frames than not need lossless subframes (XLL), for instance silent frames.

Arcsoft probably gets the same errors but doesn't report them, either.
I would still use updated/DcaDec regardless of warnings:
Arcsoft is necessary for DTS-Express only, BTW remain like a option for users than prefer it.

Only when DTS-MA is "strange setup" ArcSoft remix the output channels forcing to have less volume than original. libDcaDec don't remix the channels.

Stereodude

13th April 2016, 21:22

bmcelvan

14th April 2016, 04:42

I explained it not two posts away from yours in post #13937.

Somehow I missed your post about the floating point integer math.

sorry and thanks

ron spencer

15th April 2016, 00:49

I've got a weird problem with EAC3to and my Canon video recorder (VIXIA HF G30). EAC3to can parse all output formats from it EXCEPT 1080p 60fps. I get this error:

M2TS, 2 video tracks, 0:07:53, 60p /1.001
1: h264/AVC, 1080p60 /1.001 (16:9)
2: MPEG2, unknown parameters
Bitstream parsing for track 2 failed. <WARNING>
Demuxing this track may still produce correct results - or not. <WARNING>

Track 2 is just PCM audio...not sure why EAC3to cannot parse it. 1080i at 60 60fps is fine. I can upload something if needed to dev if interested.

thx.

ron spencer

17th April 2016, 15:52

Guess I was too stupid to upload the file...LOL

https://www.sendspace.com/file/yvv7re

File size is just 19.1 MB

Any ideas?

Groucho2004

17th April 2016, 16:24

I've got a weird problem with EAC3to and my Canon video recorder (VIXIA HF G30). EAC3to can parse all output formats from it EXCEPT 1080p 60fps. I get this error:

Track 2 is just PCM audio...not sure why EAC3to cannot parse it. 1080i at 60 60fps is fine. I can upload something if needed to dev if interested.

thx.
TSMuxer can de-multiplex your file. Don't know why eac3to can't identify the PCM track.

ron spencer

18th April 2016, 15:56

Interesting that if I remux the MTS files to M2TS via tsmuxer the EAC3to will be ok with them.

LigH

18th April 2016, 17:33

Then the reason might be an unusual audio track ID? That may require in-depth analysis of the TS headers.

ron spencer

18th April 2016, 20:31

Here is the M2TS file mediainfo

Seems like a mystery...

ron spencer

19th April 2016, 00:04

It is the same at the MTS file that is causing the error...see here. Should I be looking elsewhere for the headers?

bmcelvan

20th April 2016, 15:33

Trying to convert a TrueHD_Atmos 7.1 channel track, tried to both flac and w64. Got the "this audio conversion not supported" error. So I then (-demux) all the tracks to a folder and then tried:
eac3to331\eac3to.exe track.thd track_16bit.flac -down16
and got this error: (Also tried to .w64) - Any ideas?
process: 1%
process: 2%
process: 3%
process: 4%
process: 5%
libav Lossless check failed - expected 00, calculated 8d.
libav Lossless check failed - expected 16, calculated 1e.
process: 6%
The libav decoder reported error -1094995529 while decoding.
Aborted at file position 234881024.

I now understand the lossless check error and am not worried about that (thank you everybody). I am asking about the error that aborted the conversion.

Stereodude

20th April 2016, 16:11

Seems like your input source is corrupt.

bmcelvan

21st April 2016, 13:46

Seems like your input source is corrupt.
Okay, errors like that usuallly mean a bad copy?

I'll try re-ripping it from BD disc.

thx

weust

26th April 2016, 20:37

I have the Blu-ray set of all four Hunger Games movies, and the Monkingjay Part 2 has a TrueHD Atmos audio track.

For some reason eac3to can't show me those TrueHD tracks.
The English audio track is a TrueHD Atmos track, while the French is a DTS-HD MA 5.1 track.
I know this, because MediaInfo and MakeMKV both see the audio tracks.

What I see with eac3to 3.31:
eac3to d: 1)
M2TS, 1 video track, 3 audio tracks, 3 subtitle tracks, 0:00:29, 24p /1.001
1: Chapters, 16 chapters
2: VC-1, 1080p24 /1.001 (16:9)
3: AC3, English, 5.1 channels, 448kbps, 48kHz, dialnorm: -27dB
4: AC3, French, 5.1 channels, 448kbps, 48kHz, dialnorm: -27dB
5: AC3, English, 5.1 channels, 448kbps, 48kHz, dialnorm: -27dB
6: Subtitle (PGS), Dutch
7: Subtitle (PGS), French
8: Subtitle (PGS), French

What MakeKMV shows me is in the screenshot.

Any idea what might cause this? And if there is anything I can do to help solve this by giving information, please let me know.

Soulvomit

29th April 2016, 22:16

Which switches or options do I use to properly convert a portion of a track? Say it's three hours long and I only want the second hour. I've read the manual but I think it's outdated because only one cut is being made and it's at the wrong start time with the options I use.

tebasuna51

7th May 2016, 22:05

12 last post moved to Splitting TrueHD stream into separate songs (http://forum.doom9.org/showthread.php?t=173484)

Overdrive80

9th May 2016, 17:47

Hi, using eac3to for transcoding to pipe to ffmpeg with this:"%rea%eac3to" %1 stdout.w64 -progressnumbers -speedup -normalize -down32 | "%rff%ffmpeg" -y -i - -c:a ac3 -b:a 640k "Japones.ac3"

I get this advice: [ac3 @ 0317e840] Using AVStream.codec to pass codec parameters to muxers is deprecated, use AVStream.codecpar instead. What do it means? Thanks

Motenai Yoda

20th May 2016, 12:42

about the new loudnorm of ffmpeg, it can be integrated into eac3to?
http://k.ylo.ph/2016/04/04/loudnorm.html
IIRC the only normalization filter eac3to has is a 2 pass peak detection

tebasuna51

23rd May 2016, 11:48

Seven off topic post's moved to Split ac3 in 5.1 and 2.0 (http://forum.doom9.org/showthread.php?t=173525)

Music Fan

28th May 2016, 11:12

I have a strange problem with eac3to ; it does not detect any audio (only video) in some of my HDTV recordings (h264 in TS). And it's not due to the format because those whose sound is detected come from the same TV channel than the others (it's always ac3).
It's maybe related to TSDoctor which I use to remove some garbage and unneeded audio tracks. But with some TS files that passed through TSDoctor, there is no problem, thus I don't know what's happening.
And it does not seem either related to the size of the files.
And I like to use eac3to to demultiplex audio and video of my HDTV recordings because it detects the correct delay (unlike MediaInfo and TSMuxer) and cuts the unneeded part of the sound at the beginning (because there is a negative delay on all my recordings).

stax76

31st May 2016, 16:04

here is a problem reported by a StaxRip user:

another issues, when I'm encoding audio from AC3 using default AAC VBR 112kbps profile, audio duration doubled up
Audio source http://pastebin.com/Bc1MS4ea
Encoded audio (duration doubled) http://pastebin.com/pCp7PG15
Log http://pastebin.com/TtfWBvg3
profile used (default) http://s33.postimg.org/4odvh2pxb/Capture.png

tebasuna51

31st May 2016, 22:12

here is a problem reported by a StaxRip user:
There are something wrong in this ac3 file, maybe a mix of 2.0 and 5.1 frames.

An ac3 2.0, 48 KHz, 56m 9s decoded to wav 64 bits have a size:

3369 s * 48000 * 64 * 2 / 8 = 2587392000 bytes = 2.4 GB

but eac3to say:

Caution: The WAV file is bigger than 4GB. <WARNING>

Use DelayCut to fix the ac3 and put here the log.

stax76

1st June 2016, 07:56

@tebasuna51

Thanks for examining it, I notified the user about your reply.

IbrahimKh

1st June 2016, 13:52

There are something wrong in this ac3 file, maybe a mix of 2.0 and 5.1 frames.

An ac3 2.0, 48 KHz, 56m 9s decoded to wav 64 bits have a size:

3369 s * 48000 * 64 * 2 / 8 = 2587392000 bytes = 2.4 GB

but eac3to say:

Caution: The WAV file is bigger than 4GB. <WARNING>

Use DelayCut to fix the ac3 and put here the log.

Yes it's mix of 2.0 and 5.1
thanks for reply

stax76

2nd June 2016, 14:06

Is my list incomplete?

AC3
AC3 EX
AC3 Surround
DTS
DTS Express
DTS Hi-Res
DTS Master Audio
DTS-ES
E-AC3
E-AC3 Surround
RAW/PCM
TrueHD/AC3
TrueHD/AC3 (Atmos)

1: Chapters, 16 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: DTS Master Audio, English, 5.1 channels, 16 bits, 48kHz
(core: DTS, 5.1 channels, 1509kbps, 48kHz)
4: DTS, English, 2.0 channels, 768kbps, 48kHz

tebasuna51

2nd June 2016, 21:54

Is my list incomplete?

Nope, if is a list of audio from BD's.

But eac3to can decode other audio formats MP1, MP2, MP3, FLAC, MLP, AAC (with Nero 7 installed)...

MonoS

3rd June 2016, 21:24

Hi, some times, when i try to convert some audio tracks, lossless and lossy, to ac3 i get distorted and inaudible audio.

The problem appear randomly and re-executing the conversion fix the problem without changing anything and, if this doesn't seems to work, executing the conversion on the single audio tracks seems to fix for good.
The only thing i'm sure about the state of the pc is that it's always under heavy load when it happens [4 cores at 100%], other recurring thing are that this happens mostly demuxing blurays or converting massively multiple tracks.

This is the sample of the result, it happens randomly so i can't offer a source sample: https://mega.nz/#!OlIDVRQZ!hKwCU-3Qo0G0BFDrsp2sYqaxSIhfggH1nVOMrGf1GK8

Thanks a lot for the attention, if i can provide further information let me know

stax76

3rd June 2016, 21:30

Nope, if is a list of audio from BD's.

But eac3to can decode other audio formats MP1, MP2, MP3, FLAC, MLP, AAC (with Nero 7 installed)...

I have two lists with formats defined in StaxRip's source code regarding eac3to, BD codecs as posted and supported input file extensions:

ac3
dts
dtshd
dtshr
dtsma
eac3
evo
flac
m2ts
mlp
mp2
mpa
pcm
raw
thd
thd+ac3
ts
vob
wav

It's somehow important that my BD codecs list is complete because for a unknown codec StaxRip will:

throw a unhandled exception

prompt the user to send the log file

terminate

It happened last week for 'E-AC3 Surround', that's why I ask.

tebasuna51

4th June 2016, 11:20

...supported input file extensions:
You can add: mkv, mpls, mp1, mp3, w64 and rf64

It happened last week for 'E-AC3 Surround', that's why I ask.
I never see a E-AC3 Surround and don't know if can be a problem for eac3to.

BTW I can talk you about 'AC3 Surround':

eac3to show the qualifier 'Surround' based in a flag in AC3 header than say the user: this stereo audio have surround channels encoded in DPL style.

When a player, with DPL decoder inside, see that flag can do the extraction of surround channels.

But eac3to do nothing with that info and decode the AC3 like 2.0 because don't have a DPL decoder inside.

I only can supose than eac3to try to decode 'E-AC3 Surround' only like 2.0 ignoring the 'Surround' qualifier like with 'AC3 Surround'

tebasuna51

4th June 2016, 11:54

Hi, some times, when i try to convert some audio tracks, lossless and lossy, to ac3 i get distorted and inaudible audio.

Yes, your output is usseless and I have the same problem sometimes.

And don't know for what that happen.

stax76

4th June 2016, 11:56

@tebasuna51

Thanks for the info. :thanks:

junior_l3oss

18th June 2016, 15:51

I use Eac3to with nero without installing nero.
Eac3to only needs a couple files and registry settings
Nero Files:
- AdvrCntr2.dll
- NeAudio2.ax
- NeEacDec.dll

Copy these files in a folder of your choice. I have copied them to my eac3to folder.
Use the following command lines to register the dll's.
regsvr32.exe C:\tools\eac3to\Nero\NeAudio2.ax
regsvr32.exe C:\tools\eac3to\Nero\AdvrCntr2.dll

The following registry keys have to be added to the registry to register the nero plugin.

[HKEY_LOCAL_MACHINE\SOFTWARE\Ahead\Installation\Families\Nero 7\Info]
etc.

[HKEY_LOCAL_MACHINE\SOFTWARE\Ahead\Installation\Families\Plugins\Info]
etc.

That all you need to use the nero plugin with eac3to

i tried but i cant detect nero audio decoder.
i installed nero 7 too but not working. i tried to edit regedit...
and again i install nero 7 but there isnt neaudio2.ax
i found torrent files include it but not worked again.
my system is win 7 64bit

http://image.prntscr.com/image/7d5d1b7f33a3413d83a6b36ef7568a24.png

filler56789

18th June 2016, 16:48

i tried but i cant detect nero audio decoder.
i installed nero 7 too but not working. i tried to edit regedit...
and again i install nero 7 but there isnt neaudio2.ax

<snip>

Does this work for you?

http://forum.doom9.org/showthread.php?p=1398214#post1398214

tebasuna51

19th June 2016, 10:41

I have Nero-7.11.10.0_europe_lite installed in W7 64 bits, and the registry keys:

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Ahead\Installation\Families\Nero 7\Info]
etc.

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Ahead\Installation\Families\Plugins\Info]
etc.

BTW the Nero7 decoder is only needed now by eac3to to decode AAC standalone files, and you have other tools to do that job: qaac, ffmpeg, faad...

If the AAC is in mkv container you can use eac3to to extract the .aac

Music Fan

19th June 2016, 11:36

If the AAC is in mkv container you can use eac3to to extract the .aac
Is the result different than when done with MKVExtract ?

tebasuna51

19th June 2016, 12:39

Is the result different than when done with MKVExtract ?

Is the same, in my tests.

Music Fan

19th June 2016, 15:32

Ok thanks.

Ripman

25th June 2016, 22:07

manolito

25th June 2016, 23:03

Sorry if this has been asked before, I use eac3to only occasionally...

I need to normalize a clip, but not to 0dB, but to a lower value like -2dB or 97%. Is this possible with eac3to? The Wiki only mentions the -normalize parameter which normalizes to 0dB.

Cheers
manolito

Overdrive80

25th June 2016, 23:19

You could use -normalize for seeing ganancy that eac3to applies and after you can use +-0.0db parameters, are two passes.

manolito

26th June 2016, 02:29

tebasuna51

26th June 2016, 11:09

I downloaded 352.8khz wav files from HDtracks...
Nobody can help you because the forum rule 6 :

6) No warez, cracks, serials or illegally obtained copyrighted content! Links to content of a questionable nature (e.g. anything you don't own and/or have downloaded), asking for, offering, or asking for help/helping to process such content in any way or form is not tolerated.

Please read the forum rules.

tebasuna51

26th June 2016, 11:19

Sorry this will not do it for me...
I use this audio conversion in StaxRip, everything should be automatic without any user intervention...

Then we can't help you with that.

Ask in StaxRip thread or use MeGUI (or BeHappy) than allow this operation.

Music Fan

26th June 2016, 11:29

Sorry this will not do it for me...
I use this audio conversion in StaxRip, everything should be automatic without any user intervention.

Mostly I will convert AAC audio to AC3 audio. When converting to a lossy compressed format it is never a good idea to normalize to 0dB, I mostly leave a headroom of 2dB.

The problem is that StaxRip cannot use BeSweet for AC3 audio as the target format (this would enable normalizing to arbitrary values), it only can use eac3to.
You can do it with a free audio editor as Adobe Audition (that was earlier Cool Edit Pro).

Groucho2004

26th June 2016, 12:38

Nobody can help you because the forum rule 6
HDTracks is a legitimate site for music downloads.

Ripman

26th June 2016, 13:45

Nobody can help you because the forum rule 6 :

6) No warez, cracks, serials or illegally obtained copyrighted content! Links to content of a questionable nature (e.g. anything you don't own and/or have downloaded), asking for, offering, or asking for help/helping to process such content in any way or form is not tolerated.

Please read the forum rules.

HDtracks.com is a legitimate commercial site for hi-Rez downloads.

Anyway, they have about 80 or so new releases that are 352.8khz, and I'm trying to figure out if I can down sample these. I'll post a mediainfo report when I get in a little later.

Ripman

26th June 2016, 15:02

I downloaded 352.8khz wav files from HDtracks. I wanted to convert the wavs to 176400 so I can listen on my laptop also.

HDtracks uses a custom field in their wav files to store artwork. This field can sometimes contain many MBs of data.

I used the following command line. It all seems to work nicely. But each converted track has some pretty evil static at the very end.

Eac3to 352.wav 176.wav -resampleTo176400 -0.1dB

What should I change on the command line to get my down sampling to work properly?

As my op describes, I used the following command line with a 352khz wav file as input:
Eac3to 352.wav 176.wav -resampleTo176400 -0.1dB

The mediainfo report seemed normal for the down sampled wav, but vlc reported it as a 32bit file.

So I used the following command line:
Eac3to 352.wav 176.wav -little -24 -resampleTo176400 -0.1dB

This also resulted in a down sampled file with static at the very end. Tbh, it seems to occur only with files that have a gain applied via the "#dB" command line option.

I appreciate any ideas on this one. Thanks.

Groucho2004

26th June 2016, 15:10

As my op describes, I used the following command line with a 352khz wav file as input:
Eac3to 352.wav 176.wav -resampleTo176400 -0.1dB
Use SoX for re-sampling.

tebasuna51

26th June 2016, 17:20

HDtracks.com is a legitimate commercial site for hi-Rez downloads.

Sorry.

Eac3to 352.wav 176.wav -little -24 -resampleTo176400 -0.1dB

Please post the log file to see how eac3to recognize this wav.

But each converted track has some pretty evil static at the very end.

Maybe the wav's have extrachunks at end of files not recognized by eac3to, maybe some metadata not compliant with wav spec.

EDIT: without problems in my test:
command line: eac3to.exe 352.wav 176.wav -resampleTo176400 -0.1dB
------------------------------------------------------------------------------
WAV, 2.0 channels, 0:00:20, 16 bits, 11290kbps, 352.8kHz
Reading WAV...
Resampling to 176.4kHz...
Reducing depth from 64 to 24 bits...
Writing WAV...
Applying -0.1dB gain...
Creating file "176.wav"...
The original audio track has a constant bit depth of 16 bits.
The processed audio track has a constant bit depth of 24 bits.
eac3to processing took 2 seconds.
Done.

The resampling process is done at 64 bits, even the source is 16 bits, but by default the output is 24 bits.
Without static at end of file.

stax76

26th June 2016, 20:41

Sorry this will not do it for me...
I use this audio conversion in StaxRip, everything should be automatic without any user intervention.

Mostly I will convert AAC audio to AC3 audio. When converting to a lossy compressed format it is never a good idea to normalize to 0dB, I mostly leave a headroom of 2dB.

The problem is that StaxRip cannot use BeSweet for AC3 audio as the target format (this would enable normalizing to arbitrary values), it only can use eac3to.

What can be done is creating an audio profile based on the batch audio encoder instead of the GUI audio encoder.

it's created like so:

audio profiles menu > edit profiles > add > command line

and could look like so:

https://s31.postimg.org/q17st63az/aaa.png

Ripman

26th June 2016, 22:01

Sorry.

Please post the log file to see how eac3to recognize this wav.

Maybe the wav's have extrachunks at end of files not recognized by eac3to, maybe some metadata not compliant with wav spec.

EDIT: without problems in my test:

The resampling process is done at 64 bits, even the source is 16 bits, but by default the output is 24 bits.
Without static at end of file.

Thanks for your response buddy. Here is a log that I generated. I definitely looks like there is 24bit of audio data. Are you suggesting that I should forgo 24bit processing in favor of 16bit? (As I mentioned above, it seems like I get the "static" issue when I apply a gain.) I'm going to try SoX also.

eac3to v3.29
command line: eac3to "04-Violin Concerto, _The Red Violin__ III. Andante flautando.wav" "..\24-176.4-2\04-Violin Concerto, _The Red Violin__ III. Andante flautando.wav" -little -24 -resampleTo176400 -3.45dB
------------------------------------------------------------------------------
WAV, 2.0 channels, 0:06:29, 24 bits, 16934kbps, 352.8kHz
Reading WAV...
Resampling to 176.4kHz...
Reducing depth from 64 to 24 bits...
Writing WAV...
Applying -3.45dB gain...
Creating file "..\24-176.4-2\04-Violin Concerto, _The Red Violin__ III. Andante flautando.wav"...
The original audio track has a constant bit depth of 24 bits.
The processed audio track has a constant bit depth of 24 bits.
eac3to processing took 1 minute, 11 seconds.
Done.

Here is a mediainfo -f report for these files. (I removed the custom artwork tag.)

General
Count : 325
Count of stream of this kind : 1
Kind of stream : General
Kind of stream : General
Stream identifier : 0
Count of audio streams : 1
Audio_Format_List : PCM
Audio_Format_WithHint_List : PCM
Audio codecs : PCM
Complete name : C:\52\24-352.8-2\01-Phantasmagoria - Suite from The Ghosts of Versailles.wav
Folder name : C:\52\24-352.8-2
File name : 01-Phantasmagoria - Suite from The Ghosts of Versailles
File extension : wav
Format : Wave
Format : Wave
Format/Extensions usually used : wav
Commercial name : Wave
Internet media type : audio/vnd.wave
Codec : Wave
Codec : Wave
Codec/Extensions usually used : wav
File size : 2814506312
File size : 2.62 GiB
File size : 3 GiB
File size : 2.6 GiB
File size : 2.62 GiB
File size : 2.621 GiB
Duration : 1329205
Duration : 22mn 9s
Duration : 22mn 9s 205ms
Duration : 22mn 9s
Duration : 00:22:09.205
Duration : 00:22:09.205
Overall bit rate mode : CBR
Overall bit rate mode : Constant
Overall bit rate : 16939486
Overall bit rate : 16.9 Mbps
Stream size : 844934
Stream size : 825 KiB (0%)
Stream size : 825 KiB
Stream size : 825 KiB
Stream size : 825 KiB
Stream size : 825.1 KiB
Stream size : 825 KiB (0%)
Proportion of this stream : 0.00030
Title : Phantasmagoria - Suite from The Ghosts of Versailles
Album : Corigliano: Violin Concerto, "The Red Violin" - Phantasmagoria
Album/Performer : JoAnn Falletta
Track name : Phantasmagoria - Suite from The Ghosts of Versailles
Track name/Position : 01
Performer : Buffalo Philharmonic Orchestra
Composer : John Corigliano, Jr.
Genre : Classical Music, Orchestral
Recorded date : 2015
File creation date : UTC 2016-05-31 07:39:40.980
File creation date (local) : 2016-05-31 03:39:40.980
File last modification date : UTC 2016-05-31 07:42:47.380
File last modification date (local) : 2016-05-31 03:42:47.380
Cover : Yes
Cover description : Picture
Cover type : Cover (front)
Cover MIME : image/jpeg
Album Artist : JoAnn Falletta
Tool Name : HDtracks Downloader
Tool Version : 20.0.32

Audio
Count : 272
Count of stream of this kind : 1
Kind of stream : Audio
Kind of stream : Audio
Stream identifier : 0
Format : PCM
Commercial name : PCM
Format settings : Little / Signed
Format settings, Endianness : Little
Format settings, Sign : Signed
Codec ID : 1
Codec ID/Url : http://www.microsoft.com/windows/
Codec : PCM
Codec : PCM
Codec/Family : PCM
Codec/Info : Microsoft PCM
Codec/Url : http://www.microsoft.com/windows/
Codec/CC : 1
Codec settings : Little / Signed
Codec settings, Endianness : Little
Codec settings, Sign : Signed
Duration : 1329205
Duration : 22mn 9s
Duration : 22mn 9s 205ms
Duration : 22mn 9s
Duration : 00:22:09.205
Duration : 00:22:09.205
Bit rate mode : CBR
Bit rate mode : Constant
Bit rate : 16934400
Bit rate : 16.9 Mbps
Channel(s) : 2
Channel(s) : 2 channels
Sampling rate : 352800
Sampling rate : 352.8 KHz
Samples count : 468943520
Resolution : 24
Resolution : 24 bits
Bit depth : 24
Bit depth : 24 bits
Stream size : 2813661378
Stream size : 2.62 GiB (100%)
Stream size : 3 GiB
Stream size : 2.6 GiB
Stream size : 2.62 GiB
Stream size : 2.620 GiB
Stream size : 2.62 GiB (100%)
Proportion of this stream : 0.99970

Here is an audacity screen shot of the "noise" at the end of an eac3to 352-176 down sampled wav -- it's about 1/2 second. Again, the issue occurs when applying a gain. The source 352 wav is clean in audacity.
https://www.dropbox.com/s/ob7781uqvdy61pi/eac3to_screenshot.jpg?dl=0

manolito

26th June 2016, 22:54

What can be done is creating an audio profile based on the batch audio encoder instead of the GUI audio encoder.

Thanks Stax,
I already did exactly this...

Obviously there is no way in StaxRip to use BeSweet for AC3 audio (except using the commandline profile). This is too bad because I think that for AC3 target format BeSweet is superior to eac3to. If you use the latest bsn.dll and aften.exe by KurtNoise BeSweet is much more versatile than eac3to.

Thanks and cheers
manolito

stax76

26th June 2016, 23:57

manolito

27th June 2016, 01:11

The original Kurtnoise free.fr site seems to be down. I uploaded the two files here:
http://www13.zippyshare.com/v/SkBAb6Av/file.html

For Aften I believe that the latest Wisodev builds also work, but the safest bet is to use the latest Kurtnoise builds.

Cheers
manolito

Ripman

27th June 2016, 02:25

Use SoX for re-sampling.

Thanks. I tried SoX 14.4.2 and it works just fine. Here is the sox command line I used to replicate the one I used with eac3to.

sox -V4 352.wav --rate 176400 176.wav gain -3.5 2>sox_log.txt

tebasuna51

27th June 2016, 11:16

Obviously there is no way in StaxRip to use BeSweet for AC3 audio (except using the commandline profile). This is too bad because I think that for AC3 target format BeSweet is superior to eac3to. If you use the latest bsn.dll and aften.exe by KurtNoise BeSweet is much more versatile than eac3to.

No way to use BeSweet for that job.

1) BeSweet can't decode AAC audio

2) BeSweet can't manage wav's (the decoded AAC) bigger than 2GB.
A track 5.1 from a movie is always bigger than 2 GB.

3) The encoded AC3 is the same, not superior, to eac3to output because both use Aften.exe like encoder (using the last bsn.dll in BeSweet).

The solution proposed by Stax76 must work.

I know than eac3to can be improved with this behaviour because if you try directly:

eac3to input.aac output.ac3 -normalize -2dB

first do the -2dB gain an after normalize, then the first operation is useless.
If first normalize and after apply -2dB, or better if take the value -2dB to limit to normalize, the process can be solved with only one pass.

tebasuna51

27th June 2016, 13:31

Are you suggesting that I should forgo 24bit processing in favor of 16bit?
Nope, was just a sample than show how eac3to manage the resampling.

Here:
...
WAV, 2.0 channels, 0:06:29, 24 bits, 16934kbps, 352.8kHz
Reading WAV...
Resampling to 176.4kHz...
Reducing depth from 64 to 24 bits...
Writing WAV...
Applying -3.45dB gain...

Here is a mediainfo -f report for these files.
...
Cover : Yes
Cover description : Picture
Cover type : Cover (front)
Cover MIME : image/jpeg
Album Artist : JoAnn Falletta
Tool Name : HDtracks Downloader
Tool Version : 20.0.32

Audio
Duration : 1329205 ms
Channel(s) : 2 channels
Sampling rate : 352800
Bit depth : 24 bits
Stream size : 2813661378

Here is an audacity screen shot of the "noise" at the end -- it's about 1/2 second.

The included Artwork tag seems the problem, the WAV structure is not designed to support that metadata. Without a sample I can't know if is a violation of WAV specs or a eac3to bug.

At least eac3to don't support that (incorrect duration calculated) and artwork data considered like audio data (last noise).

Audacity show noise from original file or from the eac3to converted?
Check if Audacity support the Artwork metadata or show also noise from original wav.

I tried SoX 14.4.2 and it works just fine.

Then problem solved.

LigH

27th June 2016, 13:39

I am curious about such a WAV file too, I wrote a RIFF header analyzing tool long ago (originally MS-DOS based, rebuilt for Win32 with Lazarus) and wonder which RIFF chunks it would report (the "data" chunk is not always "the whole rest of the file after the header")... Downloading Gigabytes to obtain a sample is insane, though. Possibly.

Ripman

27th June 2016, 14:23

Thanks for he responses. I don't think the custom artwork field is the problem - the source 352 wav files play fine through my gear, and there is no static at the end that can be heard or seen with audacity. (I put a Dropbox link to a screen shot from audacity in my prior post.) I have previously processed wavs with embedded artwork from hdt in the 44khz-192khz range without issue using eac3to and a gain command line argument.

The problem only occurs when a gain is applied via the #dB command line option. I wonder if it isn't caused by expanding to 32bits to apply gain.

I have a 352khz file that's about 650mb. I'll upload the whole thing when I get in later so people can experiment.

manolito

27th June 2016, 17:22

eac3to input.aac output.ac3 -normalize -2dB

first do the -2dB gain an after normalize, then the first operation is useless.
If first normalize and after apply -2dB, or better if take the value -2dB to limit to normalize, the process can be solved with only one pass.

Sorry I am not sure if I understand you correctly...

I did try your command line with "-normalize -2dB", and the result is that eac3to first applies a -2db gain decrease and afterwards normalizes to 0dB again. Here is the log:
eac3to v3.31
command line: "E:\Programme\StaxRip\Applications\eac3to\eac3to.exe" "I:\test temp files\test ID1 - iv-Undetermined 18ms.wav" "I:\test temp files\test ID1 - iv-Undetermined 18ms_Output.ac3" -448 -normalize -2dB -down16 -progressnumbers

------------------------------------------------------------------------------
WAV, 5.1 channels, 0:05:00, 16 bits, 4608kbps, 48kHz
Reading WAV...
Reducing depth from 64 to 16 bits...
Writing WAV...
Applying -2dB gain...
Creating file "I:\test temp files\test ID1 - iv-Undetermined 18ms_Output.ac3.pass1.wav"...
The original audio track has a constant bit depth of 16 bits.
The processed audio track has a constant bit depth of 16 bits.
Starting 2nd pass...
Reading WAV...
Reducing depth from 64 to 16 bits...
Remapping channels...
Encoding AC3 <448kbps> with libAften...
Applying 3.8dB gain...
Creating file "I:\test temp files\test ID1 - iv-Undetermined 18ms_Output.ac3"...
The processed audio track has a constant bit depth of 16 bits.
eac3to processing took 2 minutes, 2 seconds.
Done.

I want to limit the normalize gain to a max peak value of -2dB, how can I achieve this with eac3to?

Another question about the command line generated by StaxRip:
Is the "down16" parameter meaningful? Does libaften cause problems with an input which has a higher bit depth?

Cheers
manolito