eac3to - audio conversion tool

[madshi]

There are a lot more "old" BD Releases which contains seemless branching and "splitted" Releases that produce Audio-Spikes
and loud noise at the cutting/fixxing Points after timecode-rerun :(

Something is borked when using DTS, no matter if it´s Arcsoft or Sonic. With AC3-Track splitting/joining is ok.

As i can remember, the same BD´s using an older eac3to version < 2.58 doesn´t produce this errors.

A good try will be Conair/German BD. Try to assemble
the GERMAN DTS Track. On the cut point there is a loud
spike on the decoded file (destination format can be WAV or AC3 - result is the same)
This should finally be fixed in the next build. The problem was caused by the RAW/PCM gap/overlap fixing code. The code was working just fine, but due to how LPCM sampling curves work, just removing a number of audio samples from an audio track can result in spikes. This problem doesn't seem to occur if the gap fixing is done on the AC3/DTS bitstream. Now the next version will contain a new post processing filter which will adjust the audio signal 0.5ms before and after the m2ts join points to make sure that there are no spikes in the final audio stream...

[bigotti5]

Can you correct delay calculation in the next build?
Closed GOPs at the beginning of a stream are misinterpreted in eac3to.
eac3to calculates delay from first I-frame, but this I-frame is third in presentation order, so -66 ms for NTSC and -80 ms for PAL is calculated.
TS, 1 video track, 1 audio track, 0:00:03
1: MPEG2, 480p30 /1.001 (4:3)
2: AC3, 5.1 channels, 448kbps, 48khz, dialnorm: -27dB, -66ms

----
File Name: closed_gop.ts
File Size: 3 533 272
Stream Type: Transport
Packets Count: 19332

.....
.....
0x00002400 PES Packet { stream_id = 0xE0 (video stream)}
packet_length = 0
PES_scrambling_control = 0
PES_priority = 0
data_alignment_indicator = 1
copyright = 0
original_or_copy = 0
PTS_DTS_flags = 3
ESCR_flag = 0
ES_rate_flag = 0
DSM_trick_mode_flag = 0
additional_copy_info_flag = 0
PES_CRC_flag = 0
PES_extension_flag = 0
PES_header_data_length = 10
PTS = 0: 10: 0: 066 (54 006 006)
DTS = 0: 9: 59: 966 (53 996 997)

0x00002413 Sequence Header
horizontal_size_value = 720
vertical_size_value = 480
aspect_ratio_information = 2 (0.673500)
frame_rate_code = 4 (29.970000)
bit_rate_value = 22500 (9000000)
marker_bit = 1
vbv_buffer_size = 112
constrained_parameters_flag = 0
load_intra_quantiser_matrix = 0
load_non_intra_quantiser_matrix = 0

0x0000241F Sequence Extention
profile_and_level_indication = 72 (Main@Main)
progressive_sequence = 1
chroma_format = 1 (4:2:0)
horizontal_size_extension = 0
vertical_size_extension = 0
bit_rate_extension = 0
marker_bit = 1
vbv_buffer_size_extension = 0
low_delay = 0
frame_rate_extension_n = 0
frame_rate_extension_d = 0

0x00002429 Sequence Display Extention
video_format = 2
colour_description = 1
colour_primaries = 6
transfer_characteristics = 6
matrix_coefficients = 6
display_horizontal_size = 720
marker_bit = 1
display_vertical_size = 480

0x00002435 User Data {}

0x00002487 Group of Picture Header #0
time = 0:0:0:0 closed_gop = 1
broken_link = 0

0x0000248F Picture Header - I Frame #0
temporal_reference = 2
picture_coding_type = 1
vbv_delay = 65535

0x00002497 Picture Coding Extention
f_code[0][0] = 15
f_code[0][1] = 15
f_code[1][0] = 15
f_code[1][1] = 15
intra_dc_precision = 2
picture_structure = 3 (Frame picture)
top_field_first = 1
frame_pred_frame_dct = 1
concealment_motion_vectors = 0
q_scale_type = 0
intra_vlc_format = 1
alternate_scan = 0
repeat_first_field = 0
chroma_420_type = 1
progressive_frame = 1
composite_display_flag = 0

.......
.......

0x00013BC8 Transport Packet { PID = 0x1011, Payload = Yes (184), Counter = 14, Start indicator }

0x00013BCC PES Packet { stream_id = 0xE0 (video stream)}
packet_length = 26939
PES_scrambling_control = 0
PES_priority = 0
data_alignment_indicator = 1
copyright = 0
original_or_copy = 0
PTS_DTS_flags = 2
ESCR_flag = 0
ES_rate_flag = 0
DSM_trick_mode_flag = 0
additional_copy_info_flag = 0
PES_CRC_flag = 0
PES_extension_flag = 0
PES_header_data_length = 5
PTS = 0: 10: 0: 000 (54 000 000)
0x00013BDA Picture Header - B Frame #1
temporal_reference = 0picture_coding_type = 3
vbv_delay = 65535
full_pel_forward_vector = 0
forward_f_code = 7
full_pel_backward_vector = 0
backward_f_code = 7

0x00013BE3 Picture Coding Extention
f_code[0][0] = 1
f_code[0][1] = 1
f_code[1][0] = 1
f_code[1][1] = 1
intra_dc_precision = 2
picture_structure = 3 (Frame picture)
top_field_first = 1
frame_pred_frame_dct = 1
concealment_motion_vectors = 0
q_scale_type = 0
intra_vlc_format = 0
alternate_scan = 0
repeat_first_field = 0
chroma_420_type = 1
progressive_frame = 1
composite_display_flag = 0
.....
.....
0x0001A7C0 PES Packet { stream_id = 0xFD (extended_stream_id)}
packet_length = 1803
PES_scrambling_control = 0
PES_priority = 0
data_alignment_indicator = 1
copyright = 0
original_or_copy = 0
PTS_DTS_flags = 2
ESCR_flag = 0
ES_rate_flag = 0
DSM_trick_mode_flag = 0
additional_copy_info_flag = 0
PES_CRC_flag = 0
PES_extension_flag = 1
PES_header_data_length = 8
PTS = 0: 10: 0: 000 (54 000 000)

0x0001A7D1 AC3 Frame
SyncInfo():
CRC1 = 22870
fscod = 0
frmsizecod = 30
SamplingRate = 48000
FrameSize = 1792
BitRate = 448000
Duration = 0.032000
BSI():
bsid = 8
bsmod = 0
acmod = 7
cmixlev = 0
surmixlev = 0
lfeon = 1
dialnorm = 27
compre = 1
compr = 4
langcode = 0
Channels = 6


Here (http://rapidshare.com/files/166647703/closed_gop.rar.html) is the above examble

eac3to should calculate either from GOP header or PTS from b-picture with temporal_reference = 0

Same in h264 files. My Sony AVCHD Cam e.g. creates h264 streams with 2 b-frames at the beginnung of the stream.

[rickardk]

Which movie is that? The warning means what it says: The ArcSoft decoder decodes this track correctly, but it lowers the volume a bit. You can more or less undo the volume change by adding "+3db" to the eac3to command line. However, perfect losslessness is lost in any case.

Why does ArcSoft lower the volume? Don't ask me. It's caused by the speaker mapping the studio has chosen. DTS-HD supports a big number of different speaker mappings for 7.1 streams. There are at least 3 different mappings the ArcSoft decoder decodes perfectly. But this specific speaker mapping used for this track seems to confuse the ArcSoft decoder, which makes it decode the track with lower volume. It's not a terribly bad thing, it's more or less similar to the effect DialNorm has. If you want, you can report this problem to the ArcSoft guys (together with a small sample). Should be easy for them to fix. Just ask them to decode the sample as 5.1 and then as 7.1. The 7.1 decoding volume will be lower, which doesn't really make any sense. With almost every other 7.1 track on the planet the 7.1 decoding volume is not lower. You can use "-logdts" to see which speaker mappings a specific 7.1 DTS-HD track uses...

Sin City (Swedish).
So ArcSoft will lower all channels with 3dB during decoding?

I will try to find where I can send the ArcSoft guys a sample.


with logdts switch:
F:\>eac3to sample.m2ts 3: e:\sample.flac -logdts
+ DTS-Core
- frameSize 2012
- DTS-ES -
- channelNo 5
- lfe 1
- channelDescr 5.1
- samplingRate 48000
- bitDepth 24
- bitrate 1536000
- samplesPerFrame 512
- copyHistory 1
+ DTS-HD
- fullSize 84
- headerSize 32
- refClockCode 1/48000
- frameDurationCode 1
- activeMasks [1], [[1]]
+ Asset [0]
- fullSize 52
- headerSize 14
- corePackets Core
- extSubStrPackets XLL
- bitResolution 24
- maxSampleRate 48000
- totalNumChannels 8
- activeSpeakers C L R Ls Rs LFE Lsr Rsr ($4f)
M2TS, 1 video track, 2 audio tracks, 4 subtitle tracks, 0:00:26
1: h264/AVC, 1080p24 /1.001 (16:9)
2: AC3, 5.1 channels, 640kbps, 48khz
3: DTS Master Audio, 7.1 (strange setup) channels, 24 bits, 48khz
(core: DTS, 5.1 channels, 24 bits, 1536kbps, 48khz)
4: Subtitle (PGS)
5: Subtitle (PGS)
6: Subtitle (PGS)
7: Subtitle (PGS)
CAUTION: Decoding this track with ArcSoft results in low volume.

[madshi]

Can you correct delay calculation in the next build?
Look two comments above yours. I already replied to you there. Delay should be correct with the next build. At least the current work in progress sources don't report any audio delay for both of your samples...

So ArcSoft will lower all channels with 3dB during decoding?
With this specific track: Yes. With most other 7.1 tracks: No.

[bigotti5]

Look two comments above yours. I already replied to you there. Delay should be correct with the next build. At least the current work in progress sources don't report any audio delay for both of your samples...

Sorry..overlooked and big thanks for your appreciated work.

[madshi]

eac3to v2.78 released

http://madshi.net/eac3to.zip

* fixed: h264 interlaced muxing to MKV could result in too long runtime
* fixed: transcoding DTS-HD/E-AC3 core sometimes failed to work correctly
* improved TS/m2ts audio delay detection
* added filter to remove spikes when fixing gaps/overlaps in RAW/PCM audio
* each eac3to instance has its own log file now
* playlist output now also works with "-log" option
* default bitrate for mono & stereo AC3 encodes lowered to 448kbps
* default bitrate for mono & stereo DTS encodes lowered to 768kbps
* it should be possible to handle TsSplitter splitted TS files via "+" now

[nwg]

Thanks for the new version.

[Chumbo]

eac3to v2.78 released

http://madshi.net/eac3to.zip

...
* each eac3to instance has its own log file now
...
Thanks so much for all the fixes and improvements and especially for adding this one. Much appreciated. :)

[Thunderbolt8]

eac3to v2.78 released
thanks! will test those interlaced h264 movies during the week!

regarding that improved m2ts audio delay correction, have there been any problems (maybe also such which werent indicated by the log?) and it was a fix, or just more like getting the already fine working detection (for most movies) more towards perfection?

[madshi]

regarding that improved m2ts audio delay correction, have there been any problems (maybe also such which werent indicated by the log?) and it was a fix, or just more like getting the already fine working detection (for most movies) more towards perfection?
Check out bigotti5's last two posts in this thread. Delay correction itself worked just fine, but delay detection was off by 2 video frames in two samples he provided. I think this problem only occurred with some movies, though, not with all. I think most Blu-Ray movies shouldn't have this problem.

[bigotti5]

Thx - works in ts-streams.
------------
Delay correction in VOB files regarding closed GOP:
- Closed GOP Video - 2 leading B-frames
- Audio AC3 - no delay
eac3to reports:
VOB, 1 video track, 1 audio track, 0:00:08
1: MPEG2, 704x576 50i (4:3)
2: AC3, 2.0 channels, 192kbps, 48khz, dialnorm: -27dB, 3ms
in VOB files delay should be calculated using 'PTS first audio' and 'Vobu Start Presentation Time'

[nurbs]

Small feature request:
Could you make the bitrate switch "-xxx" also work with the nero aac encoder? That would save me some typing. :)

[madshi]

Delay correction in VOB files regarding closed GOP:
- Closed GOP Video - 2 leading B-frames
- Audio AC3 - no delay
eac3to reports:

in VOB files delay should be calculated using 'PTS first audio' and 'Vobu Start Presentation Time'
Are you sure about that? What happens if:

- vobu start presentation time: X
- PTS first audio: X + 10ms
- PTS first video: X + 5ms

Now if you demux audio and video, audio should be delayed by 5ms and not by 10ms, or am I wrong? I can't "delay" video, so I have to delay audio by the difference between first audio and video PTS, no?

Could you make the bitrate switch "-xxx" also work with the nero aac encoder? That would save me some typing. :)
Using CBR for AAC encoding is not really a good thing for quality. VBR encoding gives better quality per average bitrate. So why would you want to use CBR?

[yesgrey]

I'm still waiting for a reply from a guy who compares a lot of resampling algorithms.

madshi,
This "guy" is not me, am I?
I'm still working on my resampler's test, and it could take a while to finish it, I have to do a few things first.
But my first test gave some interesting results, I only don't know if the results are valid enough...

[madshi]

This "guy" is not me, am I?
I'm still working on my resampler's test, and it could take a while to finish it, I have to do a few things first.
But my first test gave some interesting results, I only don't know if the results are valid enough...
I meant the maintainer of this comparison website:

http://src.infinitewave.ca/

He gave me some feedback on my early SSRC implementation, based on which I tweaked the SSRC parameters a bit.

But I'm still interesting in your comparison, too. Would be nice if you could use the latest eac3to version, because of the tweaked SSRC parameters...

As far as I understand the technical comparison website above, SSRC is a rather steep resampling filter with good results, but with "normal" ringing. r8brain filters out quite a lot of the high frequencies, but on the positive side r8brain has very reduced ringing (see pulse graph). So both filters have their advantages and disadvantages, technically.

[bigotti5]

Are you sure about that? What happens if:

- vobu start presentation time: X
- PTS first audio: X + 10ms
- PTS first video: X + 5ms

not possible - vobu start presentation time == start time of first video frame (presentation order)

[madshi]

not possible - vobu start presentation time == start time of first video frame (presentation order)
Is that written in some documentation/specification? You seem to be very sure about it. Thanks...

[nurbs]

Using CBR for AAC encoding is not really a good thing for quality. VBR encoding gives better quality per average bitrate. So why would you want to use CBR?
Because sometimes I need to hit a certain filesize. I have no problem with quality based encoding as the default, but adding the option isn't much work and it would save me some typing compared to manually piping the stdout from eac3to to the nero encoder.

[bigotti5]

Is that written in some documentation/specification?
5000$ + Non Disclosure Agreement....

But look in "Philips DVD Verifier" (https://www.ip.philips.com/download_attachment/2498/2498.pdf) documentation page 127
[A3] A VOBU‘s video presentation start time is given by the presentation start time of its first picture in DISPLAY ORDER ! Notice that in coding order this first picture (which is always an I-picture) may be preceded by some B-pictures.

[madshi]

Because sometimes I need to hit a certain filesize. I have no problem with quality based encoding as the default, but adding the option isn't much work and it would save me some typing compared to manually piping the stdout from eac3to to the nero encoder.
Ok, will add that to my to do list.

5000$ + Non Disclosure Agreement....

But look in "Philips DVD Verifier" (https://www.ip.philips.com/download_attachment/2498/2498.pdf) documentation page 127
Thanks!! Would you mind uploading the first part of that "3ms" VOB sample?

[yesgrey]

I meant the maintainer of this comparison website:

http://src.infinitewave.ca/

From that website and my first tests the winner is SOX. Have you tried it?
http://sox.sourceforge.net/

I will post my results when I have a better understanding of their correctness... I also want to compare it by earing, but I'm currently in the process of upgrading my audiogear... maybe I should post first the technical objective tests and let the subjective tests to later?...

[bigotti5]

Here (http://rapidshare.com/files/166912346/VTS_01_1.rar.html) the sample

[madshi]

From that website and my first tests the winner is SOX.
What leads you to that conclusion? Have you compared the original SSRC results or the latest eac3to implementation?

The preliminary graphs of the latest eac3to SSRC resampling implementation (v2.78) look almost identical to the SOX graphs. Have a look for yourself:

http://madshi.net/SSRC/EAC3TO.pnghttp://madshi.net/SSRC/EAC3TO_tone.png
http://madshi.net/SSRC/EAC3TO_passband.pnghttp://madshi.net/SSRC/EAC3TO_transition.png
http://madshi.net/SSRC/EAC3TO_phase.pnghttp://madshi.net/SSRC/EAC3TO_pulse.png

And these may not the final results yet. I might be able to further improve noise floor (2nd image).

[madshi]

Here (http://rapidshare.com/files/166912346/VTS_01_1.rar.html) the sample
Thanks! Will look at that later...

[rebkell]

I know this a stupid question, but I sometimes get confused about negative delays. If I have a video w/AC3 audio and eac3to reports -100ms delay, then basically eac3to will just drop the first three audio frames of the AC3 stream(around 96ms). Is that a correct assumption, and if it was 100ms delay, then it would add three 32ms frames at the start.

Would that be a correct assumption?

[yesgrey]

What leads you to that conclusion?

My first tests. Since that website results are almost identical it made me think that my tests could show something interesting...

Have you compared the original SSRC results or the latest eac3to implementation?
I have used the original SSRC HQ version. I have done this a few weeks back. I will try with your implementation, I hope it surpasses SOX!...:D

[madshi]

Would that be a correct assumption?
Yes.

My first tests. Since that website results are almost identical it made me think that my tests could show something interesting...
Do you have a software (free to share) which can produce similar graphs to those on that website? I know how to create such a sweep graph, but I don't know how to get the other ones, especially the 2nd one.

[rack04]

I'm now experiencing errors when converting the follwing DTS files to AC3.

http://www.sendspace.com/file/meghs0

eac3to v2.78
command line: eac3to "C:\Personal\Videos\dts.hires.71.24.96.2604.dtshd" "C:\Personal\Videos\dts.hires.71.24.96.2604.ac3"
------------------------------------------------------------------------------
DTS Hi-Res, 7.1 channels, 0:00:16, 24 bits, 2559kbps, 96khz
(core: DTS-ES, 5.1 channels, 0:00:16, 24 bits, 1509kbps, 48khz)
AC3 encoding doesn't support back channels. Will mix them into the surround.
Decoding with ArcSoft DTS Decoder...
Mixing surround channels...
Loading white noise (needed for dithering)...
Encoding AC3 <640kbps> with libAften...
Initialization of the AC3 encoder failed.
Aborted at file position 16384.

eac3to v2.78
command line: eac3to "C:\Personal\Videos\nature01.50ch.96kHz.24bit.ma.dtshd" "C:\Personal\Videos\nature01.50ch.96kHz.24bit.ma.ac3"
------------------------------------------------------------------------------
DTS Master Audio, 5.0 channels, 24 bits, 96khz
(core: DTS, 5.0 channels, 24 bits, 1509kbps, 48khz)
Decoding with ArcSoft DTS Decoder...
The AC3 encoder received a non-supported data format (pcm, 5, 24, -).
Aborted at file position 16384.

eac3to v2.78
command line: eac3to "C:\Personal\Videos\nature02.50ch.96kHz.24bit.ma.dtshd" "C:\Personal\Videos\nature02.50ch.96kHz.24bit.ma.ac3"
------------------------------------------------------------------------------
DTS Master Audio, 5.0 channels, 24 bits, 96khz
(core: DTS, 5.0 channels, 24 bits, 1509kbps, 48khz)
Decoding with ArcSoft DTS Decoder...
The AC3 encoder received a non-supported data format (pcm, 5, 24, -).
Aborted at file position 16384.

Also when using the -test command I get the following errors:

http://i11.photobucket.com/albums/a199/rack04/1.jpg

http://i11.photobucket.com/albums/a199/rack04/2.jpg

[yesgrey]

Do you have a software (free to share) which can produce similar graphs to those on that website? I know how to create such a sweep graph, but I don't know how to get the other ones, especially the 2nd one.

No. I also don't know how to get the other ones... but I think I have a file with instructions for it, let me look in my PC to find it.

Do you want to keep this discussion in this thread? I think it would be a better idea starting a new thread just about resamplers... If you want I can start it and post my first test results...

[tebasuna51]

I'm now experiencing errors when converting the follwing DTS files to AC3:
...
DTS Hi-Res, 7.1 channels, 0:00:16, 24 bits, 2559kbps, 96khz

Ac3 don't support 96 KHz. This work for me:

eac3to "dts.hires.71.24.96.2604.dtshd" xx.ac3 -resampleTo48000

...
DTS Master Audio, 5.0 channels, 24 bits, 96khz

Also need the 48 KHz conversion, but I don't remember if 5.0 is supported by eac3to (only 2.0 or 5.1?). This workaround can be used:

eac3to "nature02.50ch.96kHz.24bit.ma.dtshd" stdout.wav -resampleTo48000 | Aften -b 640 - xx.ac3

[bigotti5]

As stated earlier in this thread I tried to concatenate AVCHD clips from my Sony Cam using eac3to and its gap/overlapping feature.
But concatenating clips results in increasing negative audio delay.

First demux log from eac3to:

M2TS, 1 video track, 1 audio track, 1 subtitle track, 0:17:06
1: h264/AVC, 1440x1080 50i (16:9)
2: AC3, 5.1 channels, 448kbps, 48khz
3: Subtitle (PGS)
[v01] Extracting video track number 1...
[a02] Extracting audio track number 2...
[v01] Creating file "D:\MKV\video.h264"...
[a02] Creating file "D:\MKV\audio.ac3"...
[a02] Audio overlaps for 36ms at playtime 0:00:45.
[a02] Audio overlaps for 28ms at playtime 0:01:44.
[a02] Audio overlaps for 36ms at playtime 0:01:56.
[a02] Audio overlaps for 36ms at playtime 0:02:59.
[a02] Audio overlaps for 28ms at playtime 0:03:11.
[a02] Audio overlaps for 44ms at playtime 0:03:30.
[a02] Audio overlaps for 20ms at playtime 0:03:47.
[a02] Audio overlaps for 44ms at playtime 0:04:08.
[a02] Audio overlaps for 44ms at playtime 0:05:13.
[a02] Audio overlaps for 44ms at playtime 0:07:37.
[a02] Audio overlaps for 44ms at playtime 0:08:38.
[a02] Audio overlaps for 44ms at playtime 0:09:29.
[a02] Audio overlaps for 20ms at playtime 0:10:35.
[a02] Audio overlaps for 44ms at playtime 0:11:51.
[a02] Audio overlaps for 28ms at playtime 0:13:07.
[a02] Audio overlaps for 28ms at playtime 0:13:42.
[a02] Audio overlaps for 28ms at playtime 0:14:19.
[a02] Audio overlaps for 36ms at playtime 0:15:30.
[a02] Audio overlaps for 44ms at playtime 0:15:52.
[a02] The audio file was demuxed without making use of the gap/overlap information.
[a02] Please rerun the same eac3to command line. That will correct the gaps/overlaps.
Video track 1 contains 51348 frames.
eac3to processing took 58 seconds.
Done.

I just analyzed my clips and found a 20 ms difference to eac3to
Start Delay in all clips is 1:040

Clip1
last Video PTS: 45:720
correct Start Delay: 44:680
Duration (adding duration of last video frame): 44:720
last Audio PTS: 45:744
correct Start Delay: 44:704
Duration (adding duration of last audio frame): 44:736
16 ms

Clip2
last Video 1.00:800 = 59:760 = 59:800
last Audio 1.00:816 = 59:776 = 59:808
8 ms

Clip3
last Video 12:440 = 11:400 = 11:440
last Audio 12:464 = 11:424 = 11:456
16 ms

Clip4
last Video 1.04:440 = 1.03:400 = 1.03:440
last Audio 1.04:464 = 1.03:424 = 1.03:456
16 ms

....
....

So I assume these differences results in increasing delay.

[madshi]

Also when using the -test command I get the following errors
Argh, will fix that in the next build. For now you can simply delete the whole "plugin" folder. It's not needed yet, anyway.

Do you want to keep this discussion in this thread? I think it would be a better idea starting a new thread just about resamplers... If you want I can start it and post my first test results...
Starting a new thread would make sense...

Ac3 don't support 96 KHz. This work for me:

eac3to "dts.hires.71.24.96.2604.dtshd" xx.ac3 -resampleTo48000
Ah yes. eac3to automatically downmixes 7.1 to 5.1, but it doesn't automatically activate 96khz -> 48khz resampling yet. I'll add that to my to do list...

Also need the 48 KHz conversion, but I don't remember if 5.0 is supported by eac3to (only 2.0 or 5.1?).
5.0 AC3 encoding is not supported yet by eac3to.

As stated earlier in this thread I tried to concatenate AVCHD clips from my Sony Cam using eac3to and its gap/overlapping feature.
But concatenating clips results in increasing negative audio delay.
The big question is whether the video in your clips is encoded as single interlaced fields or as interlaced frames? In the first case a video field is 20ms long, in the 2nd case the frame is 40ms long. But now that I think about it, I think eac3to's gap/overlap correction doesn't properly detect these cases. I think for an interlaced stream (regardless of whether the stream is encoded as fields or frames) eac3to always calculates with only 20ms. Which is not correct. But still the results you get could be correct if your stream consists of single encoded fields, only. Is that the case?

[evdberg]

Is it correct that eac3to does not detect DD+ tracks in M2TS files (streamtype == 0x84)? Also it seems that a DD+ track on BD has a DD core inside, just like TrueHD. The PS3 shows a 640kbps 5.1 DD track when playing the file with a 7.1 DD+ track.

[bigotti5]

I think for an interlaced stream (regardless of whether the stream is encoded as fields or frames) eac3to always calculates with only 20ms. Which is not correct. But still the results you get could be correct if your stream consists of single encoded fields, only. Is that the case?
Stream consists of single encoded fields but PES packet header containing PTS spans always two fields.
Duration of clips is always a multiple of 40 ms (PAL).
An example of such a stream is in post #7054 (http://forum.doom9.org/showthread.php?p=1214448#post1214448)

[madshi]

Is it correct that eac3to does not detect DD+ tracks in M2TS files (streamtype == 0x84)? Also it seems that a DD+ track on BD has a DD core inside, just like TrueHD. The PS3 shows a 640kbps 5.1 DD track when playing the file with a 7.1 DD+ track.
Currently eac3to doesn't support Blu-Ray style main audio DD+ track which have a DD core (Blu-Ray commentary tracks don't have a DD core, these are supported by eac3to). The reason for that is that the only such sample world wide seems to be from a Dolby demo disc. Do you have a real movie disc with such a track?

Stream consists of single encoded fields but PES packet header containing PTS spans always two fields.
Duration of clips is always a multiple of 40 ms (PAL).
Ok, good to know. But how is it done with 60i video and movie content? I guess with 60i video there are also always 2 fields for one PTS timestamp? So I'd have to use 33.366ms, right? How about movies with pulldown flags? 41.70833ms or 33.366ms?

[yesgrey]

When resampling a 16 bit audio file the result should not be also a 16 bit audio file? eac3to is giving me a 24 bit audio file...
Here is my log:
eac3to v2.78
command line: eac3to white44.1_16.wav white44.16_eac3to.wav -resampleTo48000
------------------------------------------------------------------------------
WAV, 2.0 channels, 0:00:10, 16 bits, 1411kbps, 44.1khz
Reading WAV...
Resampling to 48khz...
Reducing depth from 64 to 24 bits...
Writing WAV...
Loading white noise (needed for dithering)...
Creating file "white44.16_eac3to.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 1 second.
Done.

[madshi]

When resampling a 16 bit audio file the result should not be also a 16 bit audio file? eac3to is giving me a 24 bit audio file...
Resampling is done in 64bit floating point. If you want to end up with a 16bit audio track, use the "-down16" parameter. But even downconverting to 24bit already reduces quality. If you want "full" quality (I mean best resampling comparison graphs) you should use "-down32" (32bit PCM) or "-full" (64bit floating point). The "sweep" SSRC High Precision graph on the resampling comparison website looks only that bad because the SSRC standalone tool doesn't support 32bit PCM output. The dithering down to 24bit is responsible for the dark blue background in that graph.

[evdberg]

Currently eac3to doesn't support Blu-Ray style main audio DD+ track which have a DD core (Blu-Ray commentary tracks don't have a DD core, these are supported by eac3to). The reason for that is that the only such sample world wide seems to be from a Dolby demo disc. Do you have a real movie disc with such a track?
No ... I have the Dolby demo disc ... I can not get DD+ without DD core to work on BD, so I assumed that a DD core is mandatory. Which discs do have DD+ commentary tracks without DD core?

[nautilus7]

I can not get DD+ without DD core to work on BD, so I assumed that a DD core is mandatory. You mean you can't mux DD+ w/o a core inside m2ts (using tsmuxer maybe?)Which discs do have DD+ commentary tracks without DD core?
Transformers blu-ray.

[evdberg]

You mean you can't mux DD+ w/o a core inside m2ts (using tsmuxer maybe?)
I can mux it with tsmuxer, but the result won't give any sound ... at least not on the PS3. The PS3 detects a DD track with variable bitrate. This is not strange, considering that txmuxer tags the DD+ track with streamtype 0x81 (DD) instead of 0x84.
Transformers blu-ray.
I have that one only on HD-DVD ...

[bigotti5]

Ok, good to know. But how is it done with 60i video and movie content? I guess with 60i video there are also always 2 fields for one PTS timestamp? So I'd have to use 33.366ms, right?
Imho yes
How about movies with pulldown flags? 41.70833ms or 33.366ms?
Never 41.70833
Frame duration in pulldowned videos is always 33.366 ms.

[madshi]

Imho yes
Ok, thanks. Will fix that problem in the next build.

[bigotti5]

I did a test counting video frames and audio frames in one of my cam files.

Video frames: 1495 (2990 fields) = 59.800 sec | eac3to: 2988 = 59.760 sec
Audio frames: 1869 = 59.808 | eac3to: 1868 = 59.776

eac3to reports 28 ms overlapping

Concatenating this clip e.g five times results in 14948 fields reported by eac3to (2988*5 = 14940)

[madshi]

I did a test counting video frames and audio frames in one of my cam files.

Video frames: 1495 (2990 fields) = 59.800 sec | eac3to: 2988 = 59.760 sec
Audio frames: 1869 = 59.808 | eac3to: 1868 = 59.776

eac3to reports 28 ms overlapping

Concatenating this clip e.g five times results in 14948 fields reported by eac3to (2988*5 = 14940)
Hmmmm... eac3to can not be sure whether the last PES packets are complete (some streams have wrong length information in the headers, so eac3to is ignoring the length field in the PES headers). Because of that reason the last video and audio frame is currently ignored. However, if you concatenate multiple m2ts files via "+" in the command line, the last video and audio frame in each file should NOT be ignored. In other words: I don't understand why eac3to behaves that way. Can you (once again) upload that sample you tested with? Thanks!

[bigotti5]

Because of that reason the last video and audio frame is currently ignored.

If so it should report 16 ms (59.760 <-> 59.776)

edit:
via "+" in the command line, the last video and audio frame in each file should NOT be ignored.
then 14948 is correct

[madshi]

If so it should report 16 ms (59.760 <-> 59.776)
Well, the current eac3to build adds 20ms to the last video PTS for PAL interlaced content when concatenating 2 clips (as I said, will be fixed in the next build). So I'd expect eac3to to report 36ms. Don't know why it ends up with 28ms. How long is that clip you're talking about? Can you upload it for me to check out?

[bigotti5]

Misunderstanding.....16 ms is for the single file.
Concatenating does not ignore each last frame, 8 ms will be correct - adding 20 ms results in 28 ms.
So next build will fix this, thx.

Here (http://rapidshare.com/files/167564714/00062.rar.html) is the sample (75 mb)

[madshi]

Misunderstanding.....16 ms is for the single file.
Concatenating does not ignore each last frame, 8 ms will be correct - adding 20 ms results in 28 ms.
So next build will fix this, thx.

Here (http://rapidshare.com/files/167564714/00062.rar.html) is the sample (75 mb)
Yep, eac3to reports 2988 frames for the single file and 5978 (= 2990 + 2988) frames, if I use "sample.mts+sample.mts". So it works as intended. And my latest (work in progress) sources report 8ms for each overlap... :)

[cavediver]

I have figured out how to mux seemlessly branched blu-ray's to mkv using eac3to and how to create truehd, pcm and ac3 audio tracks with eac3to. But what I haven't figured out is how to put them all back together into an mkv. I've tried using both Haali and Mkvtoolnix to put both the video file and audio files into an mkv, but both indicate that the pcm and thd+ac3 audio files are not supported media files. I've been successful using tsmuxer to put the files back together, but the truehd tracks won't play in my PCH A-110 even after remuxing with txremux. So, how do I put all of the files I've created using eac3to into an mkv container?

[mikeathome]

Hi,
might have been reported already, did not read thru all 358 posts ;-)

Downsampling 6ch AAC to 2 ch AAC did not work for me. Created a 6ch ACC instead (= did nothing)

CMDLine: eac3to 6ch.aac 2ch.aac -down2

Am I missing something?

mike