eac3to v3.24 Bugs & Improvements

[BigPines]

Thanks for the DTS strange setup explanation tebasuna51.

That is indeed a strange setup. Not sure why anyone would set up their system like that (or encode for that) since there is so little separation between speakers, it would probably not make any difference to have the rear channels at all if you were using that config. So how do we know if an audio stream has been encoded for strange setup?

Mike

[tebasuna51]

eac3to say you when is a 7.1 strange setup:

DTS Master Audio, 7.1 (strange setup) channels, 24 bits, 48kHz

[BigPines]

eeeewwwww. I've never noticed that. I'll definitely have to check that out. Someone should start a list of titles that have this "problem".

So, you are saying eac3to will decode a 7.1 file differently depending on if it is strange setup or not? Shouldn't levels and delays be handled by the producer/artist? What does the encoder/decoder do differently for these type of streams? Why does eac3to need to know the difference? In my mind, the encoder should just combine 8 discrete channels of audio and it shouldn't be messing with the content at all but maybe I am wrong.

Mike

[Chumbo]

Not to keep madshi from adding mkv chapter extraction, but I think mkvtoolnix does it just fine.
So does MKVExtract, but it would be nice to just use one tool. ;)

[Hobbe]

Use ffmpeg (libav) instead of aften when encoding AC3?

[phate89]

I have 2 improvements
1) i use a lot eac3to editing and it's a pain actually that the point you use have to be bigger than the edit you do. So if you have to add 2 seconds of silence after the first second you can't, if you have to add 11 seconds of silence after 10 second you cant', if you have to add 31 seconds of silence after 30 seconds you can't and so on.

2) (probably it's not even fixable by eac3to but from the decoder), to be able to manage mixed content, i work a lot with mixed ac3 (both 2.0 and 5.1 from tv transmission recordings) and i always have to use besweet because is the only tool i know that can decode to wav without destroy the audio or to have to clean the stream. if i pass for example an audio that is all 5.1 but have a frame 2.0 at the start it considers all frames as 2.0 so the length is 3 times the original. instead besweet leave where is only 2.0 puts the sound in l and r channel and leave with silence the other 4 channels so you'll get in output a full 5.1 good track.

[tebasuna51]

1) Already included in first post: Bad checking between edit position and duration. (http://forum.doom9.org/showthread.php?p=1600983#post1600983)

2) Yes, is a decoder issue.

[BigPines]

I stumbled across what appears to be another eac3to bug. This time it showed up on The Lorax 3D. Although the disc is 3D and has an SSIF folder in the STREAM folder, eac3to does not appear to recognize it as a 3D disc. The right eye does not show up in the list of tracks nor can it be demuxed using eac3to.

Z:\Internal HD\Volumes\LORAX_NA_3D\BDMV\PLAYLIST>"C:\Program Files (x86)\eac3to\
eac3to.exe"
1) 00031.mpls, 00028.m2ts+00035.m2ts, 1:26:19
- Chapters, 20 chapters
- h264/AVC, 1080p24 /1.001 (16:9)
- DTS Master Audio, English, multi-channel, 48kHz
- DTS, Spanish, multi-channel, 48kHz
- DTS, French, multi-channel, 48kHz
- AC3, English, stereo, 48kHz
- AC3, English, stereo, 48kHz

2) 00027.mpls, 00028.m2ts, 1:02:37
- h264/AVC, 1080p24 /1.001 (16:9)
- DTS Master Audio, English, multi-channel, 48kHz
- DTS, Spanish, multi-channel, 48kHz
- DTS, French, multi-channel, 48kHz
- AC3, English, stereo, 48kHz
- AC3, English, stereo, 48kHz

3) 00030.mpls, 00035.m2ts, 0:23:42
- h264/AVC, 1080p24 /1.001 (16:9)
- DTS Master Audio, English, multi-channel, 48kHz
- DTS, Spanish, multi-channel, 48kHz
- DTS, French, multi-channel, 48kHz
- AC3, English, stereo, 48kHz
- AC3, English, stereo, 48kHz

Mike

[DarkSpace]

BigPines, does that also happen when you select a playlist or only in the general overview? Try e.g.

Z:\Internal HD\Volumes\LORAX_NA_3D\BDMV\PLAYLIST>"C:\Program Files (x86)\eac3to\eac3to.exe" 1)

It may simply not show the right eye stream because it only parses the playlist files* and not the actual files on the disc, whereas it will analyze the actual files when you specify a playlist.

* The Playlist files may or may not contain incorrect data about the streams. I think I remember a case in the eac3to thread where the Playlist file specified an AC3 track but the actual format of the track was DTS-HDMA (as correctly detected by eac3to when parsing the files).

[get8p]

If I may, I would like to suggest some features that I think are important. Consider these, please:

1) avi, mp4, mov, mpg, flv support for demux(maybe even muxing, that would be fantastic). Basically, avi/mp4 support is most important feature I think eac3to is lacking, along with..
2) Proper ac3 decoding. As a freeware progs like azid or tranzcode can properly decode ac3, it's a real shame such powerful instrument as eac3to uses nero/libav for that.
3) ac3(maybe also dts)dialnorm applying. There's also a freeware tool ChangeDN(I think it's even opersourced), which can simply apply a given dialnorm to ac3 without decoding.

/Thanks in advance

[tebasuna51]

1) avi, mp4, mov, mpg, flv support for demux(maybe even muxing...)
... that would be fantastic, yes.:)

2) Proper ac3 decoding. ... it's a real shame such powerful instrument as eac3to uses nero/libav for that.
¿What is the problem with libav decoder?

3) ac3(maybe also dts)dialnorm applying.
¿For what you need dialnorm? I think is useless.
This was discussed long time ago in the main eac3to thread.

[BigPines]

BigPines, does that also happen when you select a playlist or only in the general overview? Try e.g.

Z:\Internal HD\Volumes\LORAX_NA_3D\BDMV\PLAYLIST>"C:\Program Files (x86)\eac3to\eac3to.exe" 1)

It may simply not show the right eye stream because it only parses the playlist files* and not the actual files on the disc, whereas it will analyze the actual files when you specify a playlist.

* The Playlist files may or may not contain incorrect data about the streams. I think I remember a case in the eac3to thread where the Playlist file specified an AC3 track but the actual format of the track was DTS-HDMA (as correctly detected by eac3to when parsing the files).
Thanks for the suggestion but it didn't work. When I specified the playlist as you suggested above, I got the same results. It only shows AVC and acts as if it is a 2D disc.

It looks like this may be becoming more common too. I just found the same problem with Arthur Christmas 3D. :(

It must have something to do with the structure of the disc. I wonder if the studios are doing this on purpose or if it is just poor disc authoring? I'm going to take a look in BDEdit to see if I can see the problem and 'fix' it.

Maybe someone knows how eac3to determines if a disc is 3D? Maybe a fix could be created from the eac3to side?

Mike

[BigPines]

UPDATE ON ABOVE: This may purely be operator error. I was using decrypted backups made by MakeMkv but those don't include the necessary SSIF files so the disc was not detected as 3D. Once I backed up to an ISO, it seems to have worked. I'll confirm this is the case with both of the above titles and report back.

Mike

[get8p]

... that would be fantastic, yes.:)
So is that a "yes" or ..?

What is the problem with libav decoder?
Audio signal above 17kHz goes -2.5dB.Look here (http://forum.doom9.org/showthread.php?t=161654).

For what you need dialnorm? I think is useless.
Ah, but it's not. What if you have found out that your .ac3 has default DN(-31) whilst it should be, say, -26? I tell you what I do in this case - I go to ChangeDN prog.
It's a minor feature, yes, but it's usefull for such cases.

[tebasuna51]

So is that a "yes" or ..?
Is fantastic, but:
Guys, as I said in the eac3to thread, bugfixes and *SMALL* improvements, only. Some of what you're suggesting would be major changes.

Audio signal above 17kHz goes -2.5dB.Look here (http://forum.doom9.org/showthread.php?t=161654).
Read also the jruggle (Aften and ffmpeg/libav-AC3 developer) posts. If he consider than libav need some improvements I'm sure a libav update (the main request to madshi) can solve the problem.

Ah, but it's not. What if you have found out that your .ac3 has default DN(-31) whilst it should be, say, -26? I tell you what I do in this case - I go to ChangeDN prog.
It's a minor feature, yes, but it's usefull for such cases.
It's your opinion.

BTW:
- To extract AC3 you can use the parameter -keepDialnorm.
- To decode, or recode to other format, you can use the parameter -5dB (31-26), same effect than apply the DialNorm -26.
- To encode to AC3 you can use the external Aften encoder:
eac3to input stdout.wav | Aften -dnorm 26 [more parameters] - output.ac3

[Snowknight26]

DTS-ES 6.1 -> WAV conversion is buggy with libav.

http://forum.doom9.org/showthread.php?p=1569705#post1569705

[tebasuna51]

Yes, I was forget this bug, added to first post.

[BigPines]

I have come across another bug/problem demuxing some 3D playlists (yeah, I have been doing a lot of 3D stuff of late). The problem is, sometimes the left eye and right eye streams do not extract with the same number of frames. Usually, it is only one frame off. Below is the Finding Nemo 3D BD:


M2TS, 2 video tracks, 2 audio tracks, 1:40:54, 24p /1.001
1: Chapters, 32 chapters
2: h264/AVC (left eye), 1080p24 /1.001 (16:9)
3: h264/AVC (right eye), 1080p24 /1.001 (16:9)
4: AC3 EX, English, 5.1 channels, 640kbps, 48kHz
5: AC3 Surround, English, 2.0 channels, 320kbps, 48kHz
Creating file "00914 - Chapters.txt"...
v02 Extracting video track number 2...
a04 Extracting audio track number 4...
v03 Extracting video track number 3...
a05 Extracting audio track number 5...
v03 Creating file "00914 - 3 - h264 (right eye), 1080p24.h264"...
v02 Creating file "00914 - 2 - h264 (left eye), 1080p24.h264"...
a04 Creating file "00914 - 4 - AC3 EX, English, 5.1 channels, 640kbps, 48kHz.ac3
"...
a05 Creating file "00914 - 5 - AC3 Surround, English, 2.0 channels, 320kbps, 48k
Hz.ac3"...
v02 Video overlaps for 14 frames at playtime 0:04:46.
v02 Video overlaps for 14 frames at playtime 0:05:38.
v02 Video overlaps for 14 frames at playtime 1:33:24.
v02 Video overlaps for 14 frames at playtime 1:40:29.
v03 Video overlaps for 14 frames at playtime 0:04:46.
v03 Video overlaps for 14 frames at playtime 0:05:38.
v03 Video overlaps for 14 frames at playtime 1:33:24.
v03 Video overlaps for 14 frames at playtime 1:40:29.
a04 Audio overlaps for 6ms at playtime 0:05:38.
a04 Audio overlaps for 27ms at playtime 1:33:24.
a04 Starting 2nd pass...
a04 Realizing (E-)AC3 gaps...
a04 Creating file "00914 - 4 - AC3 EX, English, 5.1 channels, 640kbps, 48kHz.ac3
"...
Video track 2 contains 145149 frames.
Video track 3 contains 145150 frames.
eac3to processing took 26 minutes, 1 second.
Done.


Unfortunately, this causes problems for some software when we try to mux the streams back together. For instance, Scenarist BD refuses to import streams of different size (even if only off by one frame) for 3D authoring.

It seems this would be an easy fix but I admit I don't know enough to say so for sure. It seems like eac3to could be changed to not drop a frame from the left eye stream (if that is what is actually happening). If the frame is simply missing from the original left eye stream, could eac3to trim the right eye stream so the frame count matches between the two?

Mike

P.S. In the meantime, does anyone know how to get around this problem? I have tried joining a frame to the left eye using tsMuxer. This fooled Scenarist BD into accepting the files but it choked on them when it came time to mux. In desperation, I tried trimming the right eye stream using a hex editor. I couldn't figure out the frame structure of the right eye (dependent stream) so that didn't work either. :(

[hubblec4]

an other issue is eac3to dont recognizes the Total Media Thearter5(TMT) installation on Win7prox64.

[phate89]

I have a small improvement.. Right now eac3to increase or decrease volume only with an integer volume (1db -1db etc), shouldn't be difficult to add the possibility to increase even with real numbers (0.5,1.7).. it already does it when it detects clipping so it's in theory an easy change..

[madshi]

Try ripping one of these movies:
- Edward Scissorhands
- Journey to the Center of the Earth (1959)
- Poseidon Adventure

eac3to will correctly identify the audio as 3/1.

When saving the audio as FLAC it is saved as FLAC 3/1. Unfortunately there is no such thing. FLAC with 4 channels is by FLAC specification 2/2.

Any player that follows the FLAC specification, will play the center channel in the right surround speaker.

Only option to play this correctly (with FLAC) is to duplicate the surround channel and save as FLAC 3/2.
Have a look here:

http://flac.sourceforge.net/changelog.html

Search for "WAVEFORMATEXTENSIBLE". You'll find that the official flac encoder and decoder supports any channel configuration you like, by making use of a special channel mask tag in the flac header. Unfortunately this seems to be a somewhat hidden feature because the spec doesn't mention it. But still, the official encoder/decoder supports it, so that's what eac3to and madFlac are using, too, to make any channel mask work with flac. I think newer libav/ffmpeg versions support that, too. I have no intention to drop this functionality. If you don't like this, then simply don't ask eac3to to create flac files for weird channel masks.

And the second one: defined framerate conversion is ignored in some circumstances.
I've tried to reproduce that here, but I failed. Must be a very specific combination of video, audio and container parameters. Can I have a small sample, please?

eac3to cannot recognize the DDPlus audios in the bluray disk. Hope it could be solved in the new version.
It will not be solved because to my best knowledge there's only one blu-ray in the world with such a DDPlus audio track. I'm not going to spend any time on this, just to support one demo blu-ray.

I have uploaded a couple of files that illustrate the Brave/Finding Nemo TrueHD bug.
Thanks. Are you sure that the rip is clean? Can you try to update your decrypt software and rip another time, just to be safe? The warning "This track is not clean" usually only occurs if a rip is damaged. I've never seen this warning with a clean rip yet. Maybe the current AnyDVD version isn't able yet to properly decrypt those Blu-Rays?

2) (probably it's not even fixable by eac3to but from the decoder), to be able to manage mixed content, i work a lot with mixed ac3 (both 2.0 and 5.1 from tv transmission recordings) and i always have to use besweet because is the only tool i know that can decode to wav without destroy the audio or to have to clean the stream. if i pass for example an audio that is all 5.1 but have a frame 2.0 at the start it considers all frames as 2.0 so the length is 3 times the original. instead besweet leave where is only 2.0 puts the sound in l and r channel and leave with silence the other 4 channels so you'll get in output a full 5.1 good track.
In theory eac3to could make this work. It has been on my to do list for a long time, but it's not too easy to implement due to how eac3to works internally, so that's why it's still not there...

2) Proper ac3 decoding. As a freeware progs like azid or tranzcode can properly decode ac3, it's a real shame such powerful instrument as eac3to uses nero/libav for that.
Audio signal above 17kHz goes -2.5dB.Look here (http://forum.doom9.org/showthread.php?t=161654).
Actually, the link you provided shows that eac3to with libav decoding produces better results than azid for AC3 decoding. I'm not sure where you got a different idea? It seems that for E-AC3 decoding libav wasn't producing best results yet. But the test was made 1.5 years ago. Maybe the problem has been resolved in the meanwhile. In any case, I don't think azid or tranzcode can decode E-AC3? Or if they can, they're probably using libav, too, for that, and thus will produce similar results. The only decoders which seem to produce better results are the "official" ones from Nero, Cyberlink and ArcSoft. And again, this only applies to E-AC3. From what I can see, the AC3 libav decoder is best in class, according to the test you linked to.

I have come across another bug/problem demuxing some 3D playlists (yeah, I have been doing a lot of 3D stuff of late). The problem is, sometimes the left eye and right eye streams do not extract with the same number of frames. Usually, it is only one frame off.
How can I reproduce that? Maybe you can upload the very last m2ts file of a seamless-branching Blu-Ray, if it's a rather small file?

[IanD]

It will not be solved because to my best knowledge there's only one blu-ray in the world with such a DDPlus audio track. I'm not going to spend any time on this, just to support one demo blu-ray.

The new release title "Brave" appears to flag/encode the embedded companion DD track as DD+ and this may be (partly or wholely) responsible for audio dropouts when playing the disc in some Bluray/AVR combinations or remuxing issues with eac3to.

If eac3to can not handle this, then the studios have found a way to thwart copying without errors and this approach is likely to be used on many more titles if proven effective. If you can solve this, I think it will offer dividends in the future.

[madshi]

Argh, I had hoped we'd never see E-AC3 used for Blu-Ray primary tracks... :(

[tebasuna51]

But the embedded DD track is standard AC3, at least in spanish edition, and eac3to can extract the AC3 (see http://forum.doom9.org/showthread.php?p=1600694#post1600694 ).

eac3to v3.24
command line: "D:\Programa\eac3to\eac3to.exe" "D:\Temp\BRAVE\BDMV\PLAYLIST\00801.mpls" 1)
------------------------------------------------------------------------------
M2TS, 1 video track, 10 audio tracks, 14 subtitle tracks, 1:34:12, 95.907p
1: Chapters, 37 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: TrueHD/AC3, English, 7.1 channels, 48kHz
(embedded: AC3, 5.1 channels, 640kbps, 48kHz)
4: AC3 Surround, English, 2.0 channels, 320kbps, 48kHz
5: AC3 Surround, English, 2.0 channels, 320kbps, 48kHz
6: AC3, Spanish, 5.1 channels, 640kbps, 48kHz
7: AC3, Catalan, 5.1 channels, 640kbps, 48kHz
8: AC3, Portuguese, 5.1 channels, 640kbps, 48kHz
9: AC3, Russian, 5.1 channels, 448kbps, 48kHz
10: AC3, Ukrainian, 5.1 channels, 448kbps, 48kHz
11: AC3, Kazakh, 5.1 channels, 448kbps, 48kHz
12: AC3, English, 2.0 channels, 320kbps, 48kHz
13: Subtitle (PGS), English
14: Subtitle (PGS), English
15: Subtitle (PGS), Spanish
16: Subtitle (PGS), Portuguese
17: Subtitle (PGS), Russian
18: Subtitle (PGS), Ukrainian
19: Subtitle (PGS), English
20: Subtitle (PGS), Spanish
21: Subtitle (PGS), Portuguese
22: Subtitle (PGS), Russian
23: Subtitle (PGS), Ukrainian
24: Subtitle (PGS), Portuguese
25: Subtitle (PGS), English
26: Subtitle (PGS), Ukrainian

Can't decode/extract TrueHD but work with the AC3.
Also show a fake fps: 95.907p (correct with individual m2ts files)

[IanD]

But the embedded DD track is standard AC3, at least in spanish edition, and eac3to can extract the AC3 (see http://forum.doom9.org/showthread.php?p=1600694#post1600694 )

It's obviously varying between different region releases.

See http://forum.doom9.org/showthread.php?p=1601081#post1601081 for a "Brave" issue.

It also affects some "Finding Nemo": see http://forum.doom9.org/showthread.php?p=1601412#post1601412 and from other comments I suspect "Total Recall" as well.

Just because one release is okay doesn't mean that others will be and considering the number of titles with current problems (and DD+), I expect this will escalate, hence my wish for Madshi to handle DD+ if at all possible.

I do acknowledge there seem to be ways to rip to overcome the issues (apart from where one wants thd+dd+), however it would be great if eac3to handled DD+ as a matter of course (ie providing a working option to rip the thd+dd+ without errors as well as extracting thd and dd+ separately or decoding to ac3 as an option). If the studios will be using DD+ with Bluray, it would be good to be able to extract DD+ without conversion, to retain maximum fidelity, although I'm not sure how many AVR or Bluray players will handle DD+ decoding though.

In the days of HD-DVD, it was common to have an evo file that was 2 evo files joined together with different characteristics such that a file analysis returned strange frame rates, durations, etc. In practice this wasn't a problem for playback as the system simply jumped to the appropriate starting point for each segment and there was no discontinuity. It wasn't a huge issue for ripping as it was possible to edit the xml playlist to bypass any strange introductions. I'm wondering if something similar is happening with the m2ts files. I vaguely recall this issue with "Mission To Mars", where I think there was an embedded introduction. It's harder to rip this sort of thing in Bluray because it is not as amenable to editing as HD-DVD was.

[SquallMX]

But the embedded DD track is standard AC3, at least in spanish edition, and eac3to can extract the AC3 (see http://forum.doom9.org/showthread.php?p=1600694#post1600694 ).



Can't decode/extract TrueHD but work with the AC3.
Also show a fake fps: 95.907p (correct with individual m2ts files)

The American release is affected, looks like a bitrate saving way for Disney in order to include 7.1 tracks (896 Kbps vs 2048 of DTS-HD) for dubs.

[IanD]

The American release is affected, looks like a bitrate saving way for Disney in order to include 7.1 tracks (896 Kbps vs 2048 of DTS-HD) for dubs.

But why include a companion DD+ soundtrack for TrueHD? If the consumer wants better fidelity than DD, then use the TrueHD soundtrack. DD+ has to be decoded to DD anyway for output via SPDIF, so is pointless including as a companion embedded track.

I'm certain this was done deliberately to screw the rippers: it has no logical purpose for Bluray player playback.

I can understand DD+ being used for standalone dubs, although is DD+ a supported Bluray audio standard as I'm not sure many AVR handle it?

[SquallMX]

But why include a companion DD+ soundtrack for TrueHD? If the consumer wants better fidelity than DD, then use the TrueHD soundtrack. DD+ has to be decoded to DD anyway for output via SPDIF, so is pointless including as a companion embedded track.

I'm certain this was done deliberately to screw the rippers: it has no logical purpose for Bluray player playback.

I can understand DD+ being used for standalone dubs, although is DD+ a supported Bluray audio standard as I'm not sure many AVR handle it?

They are not doing that.

The DD+ is for the French 7.1 track (at 896 Kbps with a "core" 5.1 at 512 Kbps), the English track is a huge (6439 Kbps) TrueHD 24 bits/7.1, additionally Disney provides a standalone "classic" Dolby Digital 5.1 (640 Kbps) French track since DD+ is an optional audio format for blu-ray, that way every corner is covered.

Previously Disney was using DTS-HD at 2 Mbps for dubs and DTS-MA for the main language, but now they switched to Dolby, why? I don't have a F clue...

[IanD]

They are not doing that.

The DD+ is for the French 7.1 track (at 896 Kbps with a "core" 5.1 at 512 Kbps), the English track is a huge (6439 Kbps) TrueHD 24 bits/7.1, additionally Disney provides a standalone "classic" Dolby Digital 5.1 (640 Kbps) French track since DD+ is an optional audio format for blu-ray, that way every corner is covered.

Previously Disney was using DTS-HD at 2 Mbps for dubs and DTS-MA for the main language, but now they switched to Dolby, why? I don't have a F clue...

They are including a DD+ embedded companion track with some TrueHD soundtracks according to the results of eac3to, but not on every release of a particular title.

I expect DD+ offers the opportunity to get better fidelity than DD at lower bitrates than DTS-HD or TrueHD.

Why change to Dolby? IMO, there was originally a push to DTS because the open source community had not developed decoders (unlike for TrueHD) and this made life a bit more difficult when it came to ripping and playback: now I understand there are ways to decode DTS, so I think the studios have gone back to Dolby, but started to use DD+ to make it that much more difficult again. I hear that some titles are starting to come out with 10.1 DTS and you can guarantee this will make ripping and playback a little more difficult for DTS, so I fully expect the studios to start to swing back to DTS again after this latest Dolby fad. It's just part of the cat and mouse game between the studios and the rippers: one always trying to keep a step ahead in thwarting the plans of the other.

A similar process has been trialled with Cinavia: only releasing a few titles initially to see how well it works in flummoxing the market. The when it does appear to work, ramp up the titles with it. As soon as the hackers find a way to workaround the protection, introduce something else, rinse and repeat.

[madshi]

They are including a DD+ embedded companion track with some TrueHD soundtracks according to the results of eac3to
I'm pretty sure this is not true because I don't think it's even legal to have a TrueHD audio track with an embedded DD+ track. The reason why eac3to can't decode some TrueHD tracks has nothing to do with which kind of (E-)AC3 track is embedded. eac3to does not even send the embedded (E-)AC3 frames to the TrueHD decoder.

[shon3i]

According BD specs, core/embedded track of TrueHD can be only classical DD not DD+, but also DD+ must have embedded DD track on blu-ray

[madshi]

According BD specs, core/embedded track of TrueHD can be only classical DD not DD+
That's what I had in mind, too.

but also DD+ must have embedded DD track on blu-ray
Yes, but that only applies to primary audio streams. Secondary audio streams (for PiP content like director's comments) is straight DD+, usually stereo, without a DD core.

[nevcairiel]

Wait wait, there is actually a real world disc now with a DD+ primary audio track? Oh noes.

Edit:
And i actually have a copy of "Brave" with a German track in DD+ 7.1, oh well.

[madshi]

I hoped this day would never come. Guess we have no excuses now, anymore... :(

[SquallMX]

I hear that some titles are starting to come out with 10.1 DTS and you can guarantee this will make ripping and playback a little more difficult for DTS, so I fully expect the studios to start to swing back to DTS again after this latest Dolby fad. It's just part of the cat and mouse game between the studios and the rippers: one always trying to keep a step ahead in thwarting the plans of the other.


These are just standard DTS-MA 7.1 tracks with additional metadata for a proper 11.1 upmix.

[IanD]

These are just standard DTS-MA 7.1 tracks with additional metadata for a proper 11.1 upmix.

Any bets on whether the metadata screws up some decoders?

I know these things are supposed to be backwards compatible, but in reality I don't think it is ever 100%.

Doesn't DTS 6.1 cause some issues for some decoders, for example? They should only use 7.1 for compatibility with all equipment (and simply duplicate the mono rear), yet there are a number of 6.1 soundtracks around. Standards are way too lax IMO.

[madshi]

eac3to v3.25 released

http://madshi.net/eac3to.zip

* fixed: option "-down6" didn't handle 6.1 tracks properly
* fixed: option "-down6" for 7.1 content lowered side channels in volume
* fixed: 6.1 DTS/E-AC3 libav decoding resulted in incorrect 70f channel mask
* fixed: a couple of funny AC3 channel configs resulted in swapped channels
* fixed: option "-check" failed for SRT subtitles
* fixed: MKV tracks without language information didn't default to "English"
* fixed: 16bit MLP decoding didn't work at all
* fixed: DTS 2.1 decoding had empty sub channel when using ArcSoft decoder
* fixed: muxing h264 video streams without VUI eventually crashed
* fixed: SMPTE 302M 20bit PCM tracks didn't extract properly
* improved AC3 seamless branching handling by detection of identical frames
* improved DTS seamless branching handling by detection of identical frames
* updated to latest ffmpeg/libav revision
* added support for libav DTS 6.1 and 7.1 decoding (only in core, no DTS-HD)
* added support for encoding all AC3 channel configurations
* added support for demuxing Blu-Ray primary E-AC3 tracks (AC3 core)
* libav is now the default decoder for AC3 and E-AC3
* option "-down2" is now deprecated, but still supported
* option "-downDpl" mixes down to Dolby Pro Logic II
* option "-downStereo" mixes down to standard stereo
* added support for mixing any channel configuration to stereo/DPL
* DPL downmixing doesn't lower volume, anymore (except when clipping occurs)
* editing audio tracks by adding silence is now less restrictive
* trying to mux right eye stream to MKV errors out now, instead of crashing
* doing "eac3to 1) movie.mkv" for 3D BDs now properly skips right eye stream
* FLAC encoding is now done with optimized block sizes for "LossyWAV" files
* encoder bitdepth for lossy DTS tracks is no longer displayed
* option "-test" no longer checks mkvtoolnix
Thanks to tebasuna51 for moderating the bug/improvement list, and for investigating the "duplicate frame" stuff for seamless branching Blu-Rays. I didn't know that overlapping AC3 and DTS frames were actually bit-wise identical! With this information eac3to can now discard such frames immediately, which means that it's no longer necessary to do a 2nd pass for seamless branching Blu-Rays to fix audio overlaps. This new logic should also avoid any audio glitches at the seamless branching edit points - because simply no edits are necessary, anymore, at all. Please note that this only applies to AC3 and DTS (and DTS-HD/MA) tracks. It does not apply to LPCM and TrueHD tracks. However, overlaps with LPCM and TrueHD tracks are rather small, so overlap editing is often not necessary for such tracks, anyway. The new logic also only works if the overlapping AC3 and DTS frames are truely identical. They have been with the 2 Blu-Rays I've tested with. But I don't know for sure if that's the case for *all* seamless branching Blu-Rays. So there's a chance the old overlap logic might still be used for some Blu-Rays.

It seems that mono TrueHD decoding is currently broken when using libav/ffmpeg decoding, but I'm not 100% sure because I only have one such sample and it's pretty short. Maybe you guys can double check (and provide me with a longer sample)? This looks like a libav/ffmpeg bug to me, though, if it's really a bug at all. At least Brave TrueHD decoding seems to be working fine now.

Please note that although eac3to now supports parsing, demuxing and core-extraction for Blu-Ray primary E-AC3 tracks, currently no decoder is available which can decode the full audio information with all 6.1/7.1 channels. Currently only the AC3 core can be decoded which results in 5.1 output only.

[Pomegranate]

Hi! Thank you very much for v3.25. I'm eager to try it out!

"libav is now the default decoder for AC3 and E-AC3"
Does this mean I can get rid of Nero 7 now?

[nautilus7]

Thanks for the update!

[tebasuna51]

Thank you madshi!

We have work for this new year: test all the changes.

[sl1pkn07]

in 3.24 and 3.25

sl1pkn07@sL1pKn07 STREAM $ eac3to 00005.m2ts esee.mkv
trace:loaddll:load_builtin_dll Loaded L"KERNEL32.dll" at 0x7b810000: builtin
trace:loaddll:load_native_dll Loaded L"C:\\eac3to\\eac3to.exe" at 0x400000: native
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\advapi32.dll" at 0x7ea90000: builtin
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\gdi32.dll" at 0x7eb00000: builtin
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\version.dll" at 0x7eff0000: builtin
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\user32.dll" at 0x7ec20000: builtin
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\rpcrt4.dll" at 0x7e790000: builtin
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\ole32.dll" at 0x7e820000: builtin
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\oleaut32.dll" at 0x7e960000: builtin
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\comctl32.dll" at 0x7e680000: builtin
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\shlwapi.dll" at 0x7e3d0000: builtin
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\shell32.dll" at 0x7e450000: builtin
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\mpr.dll" at 0x7e2f0000: builtin
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\wininet.dll" at 0x7e350000: builtin
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\winspool.drv" at 0x7e310000: builtin
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\comdlg32.dll" at 0x7e200000: builtin
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\ws2_32.dll" at 0x7e1b0000: builtin
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\iphlpapi.dll" at 0x7e190000: builtin
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\wsock32.dll" at 0x7e1e0000: builtin
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\msacm32.dll" at 0x7e0b0000: builtin
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\winmm.dll" at 0x7e0d0000: builtin
trace:loaddll:load_native_dll Loaded L"C:\\eac3to\\libAften.dll" at 0x10000000: native
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\msvcrt.dll" at 0x7dff0000: builtin
trace:loaddll:load_native_dll Loaded L"C:\\eac3to\\libFlac.dll" at 0x340000: native
trace:loaddll:load_native_dll Loaded L"C:\\eac3to\\libSsrc.dll" at 0x370000: native
trace:loaddll:load_native_dll Loaded L"C:\\eac3to\\hdcd.dll" at 0x5f0000: native
trace:loaddll:load_native_dll Loaded L"C:\\eac3to\\libMatrix.dll" at 0x3a0000: native
trace:loaddll:load_native_dll Loaded L"C:\\eac3to\\avutil-52.dll" at 0x66d80000: native
trace:loaddll:load_native_dll Loaded L"C:\\eac3to\\avcodec-54.dll" at 0x6a0c0000: native
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\winex11.drv" at 0x7de70000: builtin
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\uxtheme.dll" at 0x7de30000: builtin
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\imm32.dll" at 0x7dc60000: builtin
fixme:msg:ChangeWindowMessageFilter 400 00000001
M2TS, 1 video track, 1 audio track, 0:01:32, 24p /1.001
1: h264/AVC, 1080p24 /1.001 (16:9)
2: RAW/PCM, Japanese, 2.0 channels, 16 bits, 48kHz
a02 Extracting audio track number 2...
v01 Extracting video track number 1...
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\dsound.dll" at 0x7db50000: builtin
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\msvfw32.dll" at 0x7db30000: builtin
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\quartz.dll" at 0x7d920000: builtin
a02 Reading RAW/PCM...
a02 Swapping endian...
v01 Muxing video to Matroska...
trace:loaddll:load_native_dll Loaded L"C:\\Program Files\\Haali\\MatroskaSplitter\\mkzlib.dll" at 0x5350000: native
trace:loaddll:load_native_dll Loaded L"C:\\Program Files\\Haali\\MatroskaSplitter\\mkunicode.dll" at 0x5370000: native
trace:loaddll:load_native_dll Loaded L"C:\\Program Files\\Haali\\MatroskaSplitter\\splitter.ax" at 0x52c0000: native
a02 Encoding FLAC with libFlac...
v01 Starting DirectShow conversion failed.
a02 Creating file "esee - 2 - PCM, Japanese, 2.0 channels, 16 bits, 48kHz.flac"...
-------------------------------------------------------------------------------
trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\quartz.dll" : builtin
trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\msvfw32.dll" : builtin
trace:loaddll:free_modref Unloaded module L"C:\\Program Files\\Haali\\MatroskaSplitter\\splitter.ax" : native
trace:loaddll:free_modref Unloaded module L"C:\\Program Files\\Haali\\MatroskaSplitter\\mkunicode.dll" : native
trace:loaddll:free_modref Unloaded module L"C:\\Program Files\\Haali\\MatroskaSplitter\\mkzlib.dll" : native
err:ole:CoInitializeEx Attempt to change threading model of this apartment from multi-threaded to apartment threaded
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\mmdevapi.dll" at 0x7dc00000: builtin
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\winealsa.drv" at 0x7db20000: builtin
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\wineoss.drv" at 0x7d9e0000: builtin
trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\wineoss.drv" : builtin
ALSA lib pcm.c:7339:(snd_pcm_recover) underrun occurred
Aborted at file position 256180224.
sl1pkn07@sL1pKn07 STREAM $

install in wine:
ffdshow 1.2.4496 (2012-12-13) (http://sourceforge.net/projects/ffdshow-tryout/files/SVN%20builds%20by%20clsid/generic%20builds/ffdshow_rev4496_20121213_clsid.exe/download)
HaaliMatroskaSplitter 1.11.288.0 (fom CoreAVC 3.0.1 proffesional), test with official haali and still fail
mkvtoolnix 5.9.0-unicode (not need in 3.25?)

linux:
wine-1.5.20 with external "bottle" only for eac3to. in 32bit mode
archlinux 64bits

any ideas?

is possible add support to use mkvtoolnix/ffmpeg/libav instead to haali to make mkv?

[get8p]

Thanks a lot!

[phate89]

In theory eac3to could make this work. It has been on my to do list for a long time, but it's not too easy to implement due to how eac3to works internally, so that's why it's still not there...



Well i hope you'll find the time, for me it's a major change.. But i understand it's not a priority
What about this (in theory) simple change?

I have a small improvement.. Right now eac3to increase or decrease volume only with an integer volume (1db -1db etc), shouldn't be difficult to add the possibility to increase even with real numbers (0.5,1.7).. it already does it when it detects clipping so it's in theory an easy change..

[7ekno]

Nice update Madshi!

Does AC3 encoding now default to ffmpeg? Or is it still done via an antiquated Aften?

Only reason I ask is the FFMPEG AC3 encoder seems to be of higher quality than Aften now days ;)

7

[kukushka]

can you please get rid of the bug with pseudo dialnorm removal in dts-hd tracks? by forcing -keepdialnorm if there's no other way and probably by displaying a big fat warning when decoding dial normed dts-hd tracks with arcsoft. thanks

[tebasuna51]

The new release 3.25 work fine with my spanish release of BRAVE:

- The ac3 extracted now is bitidentical to the extracted with manual method. (http://forum.doom9.org/showthread.php?p=1600694#post1600694)

- Can extract/decode the TrueHD track, with a message:
[a03] Skipping identical AC3 frames (seamless branching)...
I don't know if the message is appropiated here.

- Can decode the extracted thd, now there are messages:
1%
[libav] Lossless check failed - expected 00, calculated 48. <WARNING>
[libav] Lossless check failed - expected 00, calculated 17. <WARNING>
4%
[libav] Lossless check failed - expected 00, calculated 9b. <WARNING>
92%
[libav] Lossless check failed - expected 00, calculated cd. <WARNING>
93%
[libav] Lossless check failed - expected 00, calculated f3. <WARNING>
99%
[libav] Lossless check failed - expected 00, calculated b0. <WARNING>
[libav] Lossless check failed - expected 00, calculated e8. <WARNING>

maybe related to seamless branching problem.

- The wav's (directly decoded and thd decoded) are bitidentical and with correct duration: 5652.23333 sec., (1h. 34m. 12.23333s.).
The video duration is: 5652.230 sec., (1h. 34m. 12.230s.)
AC3 duration: 5652,256 seconds. ( 1 h. 34 m. 12,256 s.).

All is OK, only the fake fps 95.907p remain.

[IanD]

I must apologise for leading people astray over DD+ soundtracks in "Brave" and "Finding Nemo".

I have been interpreting AC3 EX as meaning AC3 with "extensions" or DD+, when in fact I have now been informed that EX means "matrixed surround" in this instance and DD+ would actually be identified as E-AC3 (verified by testing an HD-DVD).

Surprising no-one has called me on the mistake before now as I am not an eac3to interpretation expert.

So, there probably aren't any DD+ soundtracks in the current titles causing issues (especially as companion soundtracks to TrueHD).

However, I thank Madshi for updating eac3to to better handle certain issues and it is still worthwhile to be able to handle all audio formats that the Bluray consortium might throw our way (in order to upset ripping).

[nevcairiel]

The "Brave" Blu-ray i have at home actually has a DD+ 7.1 track, its not matrixed, it truely is E-AC3 with a AC3 "core" stream and the E-AC3 dependent substream which replaces/adds new channels.
It has a TrueHD 7.1 track for english, and the DD+ 7.1 tracks for German and Italian.

Note that ripping it with eac3to will result in you having only the AC3 "core" track, which may as well be matrixed for backwards compat (the matrixed surround channels are replaced by "clean" the extra channels in the E-AC3 substream if its decoded completely)

[nautilus7]

I can also confirm that the disc has dd+ audio, but not 7.1. Only 5.1 Unless bdinfo doesn't report it correctly.
PLAYLIST REPORT:

Name: 00801.MPLS
Length: 1:34:12.229 (h:m:s.ms)
Size: 27 503 554 560 bytes
Total Bitrate: 38,93 Mbps

VIDEO:

Codec Bitrate Description
----- ------- -----------
MPEG-4 AVC Video 23859 kbps 1080p / 23,976 fps / 16:9 / High Profile 4.1

AUDIO:

Codec Language Bitrate Description
----- -------- ------- -----------
Dolby TrueHD Audio English 6439 kbps 7.1 / 48 kHz / 6439 kbps / 24-bit (AC3 Embedded: 5.1 / 48 kHz / 640 kbps)
Dolby Digital Plus Audio German 512 kbps 5.1 / 48 kHz / 512 kbps
Dolby Digital Plus Audio Italian 512 kbps 5.1 / 48 kHz / 512 kbps
Dolby Digital Audio German 640 kbps 5.1 / 48 kHz / 640 kbps
Dolby Digital Audio Italian 640 kbps 5.1 / 48 kHz / 640 kbps
Dolby Digital Audio Turkish 640 kbps 5.1 / 48 kHz / 640 kbps
Dolby Digital Audio English 320 kbps 2.0 / 48 kHz / 320 kbps / Dolby Surround
Dolby Digital Audio English 320 kbps 2.0 / 48 kHz / 320 kbps

SUBTITLES:

Codec Language Bitrate Description
----- -------- ------- -----------
Presentation Graphics English 35,887 kbps
Presentation Graphics English 23,356 kbps
Presentation Graphics English 79,675 kbps
Presentation Graphics German 26,282 kbps
Presentation Graphics German 74,753 kbps
Presentation Graphics Italian 20,312 kbps
Presentation Graphics Italian 62,818 kbps
Presentation Graphics Turkish 22,944 kbps
Presentation Graphics Turkish 69,697 kbps
Presentation Graphics Turkish 0,061 kbps

Thought, because there's also an ac3 5.1 german and italian track, it makes me think that the e-ac3 tracks are indeed 7.1 and not 5.1. I should report that to the author of bdinfo.

[tebasuna51]

@nevcairel
Then the TrueHd+AC3 (EX or not) english track seems solved.

But the German and Italian tracks are DD+ 7.1 (or 5.1 ?). How work eac3to with that track?

Reading http://en.wikipedia.org/wiki/Dolby_Digital_Plus:
"However, Dolby Digital Plus decoders include a mandatory component that directly converts (without decoding and re-encoding) the Dolby Digital Plus bitstream to a Dolby Digital bitstream (operating @ 640kbit/s) for carriage via legacy S/PDIF connections (including S/PDIF over HDMI) to external decoders (e.g. AVRs, etc.)."

Can eac3to (Nero or libav decoders) decode the track?
There are a method to extract the AC3 'core' without re-encode? (I confess that this option is new for me).