eac3to - audio conversion tool [Archive] - Page 157

KevinMcPool

12th January 2009, 12:50

--------------------------------------------------------------------------------

Using eac3to and its gui(which ive done successfully numerous times before on seamless branching titles-this one is the ext.cut of KK) ive encountered this error message whilst remuxing the dtshd to lpcm(for my pch a100)
"The temp file could not be interpreted correctly"..eac3to correctly identifies the audio overlaps..
[a05] Audio overlaps for 11ms at playtime 1:14:09.
[a05] Audio overlaps for 7ms at playtime 1:16:59.
[a05] Audio overlaps for 6ms at playtime 1:38:53.
[a05] Audio overlaps for 9ms at playtime 2:09:19.
[a05] Audio overlaps for 6ms at playtime 2:46:16.
[a05] Audio overlaps for 8ms at playtime 2:46:38.
[a05] Audio overlaps for 11ms at playtime 2:53:16.
[a05] Audio overlaps for 10ms at playtime 3:14:19
but then stops with the aforementioned error message and produces no .lpcm output just a log with the error meassage.
The same has also just happened with Close Encounters(seamless branching too)
Ive tried with eac3to latest and older versions also.
I use the sonic decoder.
Anyone help please??

madshi

12th January 2009, 13:04

madshi, what does this mean?

a03 This track begins with a non-major frame.
It means that the TrueHD track doesn't begin as it should begin technically, but eac3to works around that problem. TrueHD tracks consist of major and non-major frames. Usually a track begins with a major frame.

Using eac3to and its gui(which ive done successfully numerous times before on seamless branching titles-this one is the ext.cut of KK) ive encountered this error message whilst remuxing the dtshd to lpcm(for my pch a100)
"The temp file could not be interpreted correctly"..eac3to correctly identifies the audio overlaps..
[a05] Audio overlaps for 11ms at playtime 1:14:09.
[a05] Audio overlaps for 7ms at playtime 1:16:59.
[a05] Audio overlaps for 6ms at playtime 1:38:53.
[a05] Audio overlaps for 9ms at playtime 2:09:19.
[a05] Audio overlaps for 6ms at playtime 2:46:16.
[a05] Audio overlaps for 8ms at playtime 2:46:38.
[a05] Audio overlaps for 11ms at playtime 2:53:16.
[a05] Audio overlaps for 10ms at playtime 3:14:19
but then stops with the aforementioned error message and produces no .lpcm output just a log with the error meassage.
The same has also just happened with Close Encounters(seamless branching too)
Ive tried with eac3to latest and older versions also.
I use the sonic decoder.
Anyone help please??
Need to see the full eac3to log. From v3.01, please.

KevinMcPool

12th January 2009, 19:19

Need to see the full eac3to log. From v3.01, please.

Sorry madshi unfortunately 3.01 doesnt produce a log when i ask it to convert dtshd to lpcm from the seamless branching titles(both Close Encounters and King Kong).It merely fails with the aforementioned error message though unlike eac3to 2.87(which did produce a log) it keeps the lpcm file with the extension of pass1.lpcm...thus to summarise..
2.87-builds the lpcm file from the dtshd but then deletes it at the point of the required second pass leaving only a log file with the error message "The temp file could not be interpreted correctly"
3.01-also builds the lpcm file but also fails at the point of the second pass leaving no log file but an lpcm file e.g. "CEDirCutdtshdto.pass1.lpcm"
Here is the log from 2.87..

eac3to v2.87
command line: "C:\Documents and Settings\My Documents\eac3to287\eac3to.exe" "D:\Close Encounters\CLOSE_ENCOUNTERS\BDMV\STREAM\" 1) 4: "D:\Close Encounters\CLOSE_ENCOUNTERS\BDMV\STREAM\closeencountersdcdtshdto.lpcm"
------------------------------------------------------------------------------
M2TS, 1 video track, 2 audio tracks, 20 subtitle tracks, 2:17:13
1: Chapters, 20 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: TrueHD/AC3, English, 5.1 channels, 48khz
(embedded: AC3, 5.1 channels, 448kbps, 48khz)
4: DTS Master Audio, English, 5.1 channels, 24 bits, 48khz
(core: DTS, 5.1 channels, 24 bits, 1509kbps, 48khz)
5: Subtitle (PGS), English
6: Subtitle (PGS), English
7: Subtitle (PGS), Dutch
8: Subtitle (PGS), Arabic
9: Subtitle (PGS), Bulgarian
10: Subtitle (PGS), Croatian
11: Subtitle (PGS), Czech
12: Subtitle (PGS), Danish
13: Subtitle (PGS), Finnish
14: Subtitle (PGS), Modern Greek
15: Subtitle (PGS), Hebrew
16: Subtitle (PGS), Hindi
17: Subtitle (PGS), Hungarian
18: Subtitle (PGS), Icelandic
19: Subtitle (PGS), Norwegian
20: Subtitle (PGS), Polish
21: Subtitle (PGS), Romanian
22: Subtitle (PGS), Slovenian
23: Subtitle (PGS), Swedish
24: Subtitle (PGS), Turkish
[a04] The ArcSoft decoder doesn't seem to work, will use Sonic instead.
[a04] Extracting audio track number 4...
[a04] Decoding with DirectShow (Sonic Audio Decoder)...
[a04] DirectShow reports 5.1 channels, 24 bits, 48khz
[a04] Swapping endian...
[a04] Remapping channels...
[a04] Creating file "D:\Close Encounters\CLOSE_ENCOUNTERS\BDMV\STREAM\closeencountersdcdtshdto.lpcm"...
[a04] The last DTS frame is incomplete and thus gets skipped.
[a04] The original audio track has a constant bit depth of 24 bits.
[a04] Audio overlaps for 7ms at playtime 0:23:06.
[a04] Audio overlaps for 6ms at playtime 0:26:06.
[a04] Audio overlaps for 11ms at playtime 0:30:37.
[a04] Audio overlaps for 6ms at playtime 0:34:03.
[a04] Audio overlaps for 6ms at playtime 0:37:20.
[a04] Audio overlaps for 7ms at playtime 0:41:25.
[a04] Audio overlaps for 13ms at playtime 0:45:19.
[a04] Audio overlaps for 9ms at playtime 0:58:47.
[a04] Audio overlaps for 12ms at playtime 1:03:58.
[a04] Audio overlaps for 6ms at playtime 1:04:39.
[a04] Audio overlaps for 8ms at playtime 1:13:48.
[a04] Audio overlaps for 10ms at playtime 1:15:44.
[a04] Audio overlaps for 6ms at playtime 1:16:41.
[a04] Audio overlaps for 5ms at playtime 1:20:28.
[a04] Audio overlaps for 9ms at playtime 1:21:15.
[a04] Audio overlaps for 9ms at playtime 1:34:00.
[a04] Audio overlaps for 9ms at playtime 1:34:34.
[a04] Audio overlaps for 10ms at playtime 2:11:04.
The temp file could not be interpreted correctly.

Ive went back to my previously working method using your eac3to v2.52 and all is well..ive just to manually re-run the same command to ensure the RAW/PCM gaps are realized.

canTsTop

12th January 2009, 19:32

mbcd

12th January 2009, 22:22

hello, i am new to eac3to

here is sample http://www.mediafire.com/file/kynimztnjwe/333_0_0.ts (~65mb), duration is 3mn 34s, but after i demux it with eac3to, its only few seconds
here is log http://www.paste.lt/paste/092a8236908599b86de882c9b04966a3
it says The source file is encrypted. <WARNING>, but its not encrypted

here is another 2 samples with many errors http://www.mediafire.com/file/iqom3mziwzd/with_errors_2.ts (10mb) and http://www.mediafire.com/?zumjnyzywdy (24mb)
after i dumux them, audio is few seconds shorter then mediainfo reported on TS. is this normal?

can this tool repair video? thank you.

Your posted File (65mb-Sample) ist damaged during BAD-Signal or missing decryption for a short moment. Possibly recorded over DVB-S ?

Try to repair it with Project-X or something else.
Because of this error eac3to thinks its encrypted. Maybe there is realy a single Frame where decryption failed. I dont know if this TV-Broadcaster encypts.

Normaly something like this is not repairable. Best is to delete the damaged part and keep the rest.

eac3to can not repair such errors.

Snowknight26

12th January 2009, 23:48

It's not possible to go from DTSWAV -> DTS without some type of conversion, is it?

nautilus7

12th January 2009, 23:50

Do you mean w/o dts encoding? It is possible. Just do eac3to input.wav output.dts. If the wav is dtswav then the wav header will be stripped and you'll get raw dts file.

P.S maybe you need -768 if your dtswav is 768kbps, but i'm not sure.

jj666

13th January 2009, 01:52

Hello Madshi,

Found a strange error with 3.01 whilst remuxing two VC1 HD-DVDs I had, Shaun Of The Dead and Motorhead Stage Fright.

Demuxing the video stream (and removing pulldown) with 3.01 produces an un-usable file reported as 8168:6118p in TSMUXER. No problem at all with 2.87 and the same file/settings - reported as 1920:1080p in TSMUXER.

In case this was a problem with TSMUXER, I tried to play the VC1 stream with DGVC1DECNV which resulted in the video driver crashing. Again, no problems with the VC1 stream demuxed with 2.87.

Log files:

eac3to v3.01
command line: "E:\utils\encoding\eac3to\eac3to.exe" "E:\bd temp\Motoerhead_Stage_Fright\" 1) 3: "E:\bd temp\Motoerhead_Stage_Fright\video3.01.vc1"
------------------------------------------------------------------------------
EVO, 2 video tracks, 3 audio tracks, 1:29:59
"MainFeature"
1: Joined EVO file
2: Chapters, 22 chapters without names
3: VC-1, 1080p24 /1.001 (16:9) with pulldown flags
4: VC-1, 480i48 /1.001 (3:2)
5: DTS Hi-Res, English, 5.1 channels, 24 bits, 2046kbps, 48khz
(core: DTS, 5.1 channels, 24 bits, 1509kbps, 48khz)
6: DTS Master Audio, English, 2.0 channels, 24 bits, 48khz
(core: DTS, 2.0 channels, 24 bits, 768kbps, 48khz)
7: DTS, English, 5.1 channels, 24 bits, 768kbps, 48khz
[v03] Extracting video track number 3...
[v03] There's no valid framerate in this bitstream. <WARNING>
[v03] Writing new framerate "24fps /1.001" to bitstream.
[v03] Writing new framerate "24fps /1.001" to bitstream.
[v03] Removing VC-1 pulldown...
[v03] Creating file "E:\bd temp\Motoerhead_Stage_Fright\video3.01.vc1"...
Video track 3 contains 129453 frames.
Video track 4 contains 161802 frames.
eac3to processing took 14 minutes, 12 seconds.
Done.

eac3to v2.87
command line: "E:\utils\encoding\eac3to\eac3to2.87.exe" "E:\bd temp\Motoerhead_Stage_Fright\" 1) 3: "E:\bd temp\Motoerhead_Stage_Fright\video.vc1"
------------------------------------------------------------------------------
EVO, 2 video tracks, 3 audio tracks, 1:29:59
"MainFeature"
1: Joined EVO file
2: Chapters, 22 chapters without names
3: VC-1, 1080p24 /1.001 (16:9) with pulldown flags
4: VC-1, 480i60 /1.001 (3:2)
5: DTS Hi-Res, English, 5.1 channels, 24 bits, 2046kbps, 48khz
(core: DTS, 5.1 channels, 24 bits, 1509kbps, 48khz)
6: DTS Master Audio, English, 2.0 channels, 24 bits, 48khz
(core: DTS, 2.0 channels, 24 bits, 768kbps, 48khz)
7: DTS, English, 5.1 channels, 24 bits, 768kbps, 48khz
[v03] Extracting video track number 3...
[v03] Removing VC-1 pulldown...
[v03] Creating file "E:\bd temp\Motoerhead_Stage_Fright\video.vc1"...
Video track 3 contains 129453 frames.
Video track 4 contains 161802 frames.
eac3to processing took 10 minutes, 58 seconds.
Done.

Cheers,

-jj-

setarip_old

13th January 2009, 03:45

@jj666

Hi!

I know nothing about this software but I see that line 4 of the two logs include different values - 480i48 and 480i60...

ragboy

13th January 2009, 04:47

Snowknight26

13th January 2009, 05:18

I am having the same problem with Apollo 13

I can confirm it. After demuxing the VC-1 track muxing the first 100MB of the EVOs then muxing it with mkvmerge, libavcodec (from ffdshow r2594) crashes as soon as the file starts playing. MPC-HC r969 (internal VC-1 decoder with DXVA enabled) plays it until you stop the video, upon which it also crashes.

sidekick2

13th January 2009, 06:14

I can confirm that vc1 pulled from Bourne Ultimatum hd-dvd also shows up as 8168x6188 res, and won't play in anything when muxed in tsmuxer.

"Profile Advanced@3:Resolution: 8168:6118p Frame rate 23.976"

This is with version 3.01.

madshi

13th January 2009, 09:32

Sorry madshi unfortunately 3.01 doesnt produce a log when i ask it to convert dtshd to lpcm from the seamless branching titles
My fault. Will be fixed in the next build.

2.87-builds the lpcm file from the dtshd but then deletes it at the point of the required second pass leaving only a log file with the error message "The temp file could not be interpreted correctly"
Will be fixed in the next build.

here is sample http://www.mediafire.com/file/kynimztnjwe/333_0_0.ts (~65mb), duration is 3mn 34s, but after i demux it with eac3to, its only few seconds
here is log http://www.paste.lt/paste/092a8236908599b86de882c9b04966a3
it says The source file is encrypted. <WARNING>, but its not encrypted

here is another 2 samples with many errors http://www.mediafire.com/file/iqom3mziwzd/with_errors_2.ts (10mb) and http://www.mediafire.com/?zumjnyzywdy (24mb)
after i dumux them, audio is few seconds shorter then mediainfo reported on TS. is this normal?

can this tool repair video? thank you.
Thanks for the samples, but as mbcd already hinted, these files seem to be severely damaged, or maybe only partially decrypted. eac3to can not repair any such errors. It can only skip over errors. Which means that if the source is so much damaged, the output of eac3to can be much shorter than the source file claims to be. There's nothing I can do about that. eac3to's error tolerance just means that *minor* errors in a source file are properly ignored now (not repaired). If you have a really strongly damaged source file, just trash and rerecord.

Do you mean w/o dts encoding? It is possible. Just do eac3to input.wav output.dts. If the wav is dtswav then the wav header will be stripped and you'll get raw dts file.

P.S maybe you need -768 if your dtswav is 768kbps, but i'm not sure.
The switch is not necessary. eac3to never reencodes, unless you ask it to.

Normally eac3to does detect dtswav automatically, but there are cases where the detection does not work. Maybe I can improve on that in a future version. For now you can use DtsParser to convert dtswav files to dts. And eac3to can then in any case decode them (if needed).

Found a strange error with 3.01 whilst remuxing two VC1 HD-DVDs I had, Shaun Of The Dead and Motorhead Stage Fright.

Demuxing the video stream (and removing pulldown) with 3.01 produces an un-usable file reported as 8168:6118p in TSMUXER. No problem at all with 2.87 and the same file/settings - reported as 1920:1080p in TSMUXER.
I am having the same problem with Apollo 13, and another title
I can confirm it.
I can confirm that vc1 pulled from Bourne Ultimatum hd-dvd also shows up as 8168x6188 res, and won't play in anything when muxed in tsmuxer.
Sorry guys, BAD bug. Will be fixed in next build.

madshi

13th January 2009, 09:33

eac3to v3.02 released

http://madshi.net/eac3to.zip

* fixed: VC-1 stream handling was broken
* fixed: destination file extension "*.lpcm" didn't work with 2pass processing
* fixed: MPEG2 1088 to 1080 cropping was incomplete
* fixed: no log was being created when "temp file could not be interpreted"

madshi

13th January 2009, 11:28

eac3to v3.03 released

http://madshi.net/eac3to.zip

* fixed: MPEG2 1088 to 1080 cropping was still incomplete

ragboy

13th January 2009, 14:04

Chumbo

13th January 2009, 15:39

@madshi,
This is an aesthetic issue so no hurry, but I noticed that v3 overrides the DOS window's color settings. Would you consider not overriding this please? Thank you.

ragboy

13th January 2009, 15:58

I am using eac3to to recode DTS or EAC3 and then tsmuxer to mux to m2ts and then to Handbrake. Handbrake no longer crashes, but handbrake sees the video as 2x the length it should be. If I open the bluray stream direct, I don't have the problem, but I can't read the audio. I have a small EVO file, 65 megs, unilogo.evo, that I use to test, and eac3to 3.03 doesn't seem to work with it. I can upload the file somewhere if you like.

Momber

13th January 2009, 16:25

Found a strange error with 3.01 whilst remuxing two VC1 HD-DVDs I had, Shaun Of The Dead and Motorhead Stage Fright.
For starters, you need to use -keeppulldown with Motörhead Stagefright. It's not a 24p encoding.

rack04

13th January 2009, 18:29

I have a raw h264 stream that was encoded using x264 with the following avs script:

DirectShowSource("C:\Personal\Videos\sample.mkv", fps=23.976, audio=false)
Spline64Resize(1280,720)

When I take the raw h264 and mux to mkv using eac3to v3.03 it is reported as 23 fps.

http://www.mediafire.com/download.php?mj1tuomhmul

eac3to v3.03
command line: eac3to "C:\Personal\Videos\sample-output.h264" "C:\Personal\Videos\sample-output.mkv"
------------------------------------------------------------------------------
h264/AVC, 720p23 (16:9)
Muxing video to Matroska...
Added fps value to MKV header.
Video track 1 contains 256 frames.
eac3to processing took 1 second.
Done.

n0mag!c

13th January 2009, 19:29

:thanks: very much for your efforts!
VC-1 stream was incorporated from WMV-file.
That VC-1 stream does not have any framerate information in it. That made eac3to crash. The next build will handle this gracefully. But it will "guess" the framerate to be 23.976.
Could you please add force writting framerate information to such streams? It would be very useful!

I really don't like that the second pass is needed to eliminate clipping.There's no way to detect and fix clipping in one pass. However, you can manually lower volume by adding e.g. "-3db" to the command line. In most cases that should make sure that no clipping occurs, so no 2nd pass will be necessary.
Lowering volume is not an option, at least for me.
How exactly elimination of clipping works? If in "eac3to" there will be write buffers for output files, then how big they must be to avoid 2nd pass running? Of course if you've decided to implement this.

n0mag!c

13th January 2009, 19:43

-23.976/... define source fps to be "23.976", "24.000", "25.000", ...
-changeTo24.000 change source fps to "23.976", "24.000", "25.000", ...
-resampleTo48000 resample audio to "44100", "48000" or "96000" Hz
Is it possible to implement possibility to use ANY values for this switches? Then your tool will be ULTIMATE for resampling purposes. :)
P.S. Is "/" symbol present there by mistake?

spida_singh

13th January 2009, 19:50

Just demuxed dark knight blu ray (UK), using hd stream extractor. Video demuxed fine to mkv, audio saved as .thd (not THD+AC3). The resulting audio file is not accepted in tsmuxer,tsremux, or mkvmerge. I know Tsmuxer has issues with trued hd, but, it reads the m2ts I remuxed to an m2ts, direct from disc using TS4np 0.82. What i want to know is, does the true hd file needs to be in a container for it to be recognised in tsmuxer and ts4np (Tsremux), is it possible to take the mkv created from eac3to, and add the truehd track to make my final mkv within mvkmerge? I have deleted the log, but i know there were not any errors in the log, just need to know if anyone knows this from the top of their head, if not, ill redo the demux and post logs. :D

madshi

13th January 2009, 20:22

This is an aesthetic issue so no hurry, but I noticed that v3 overrides the DOS window's color settings. Would you consider not overriding this please?
This is slightly problematic. eac3to uses colored output now. By doing so I have to overwrite the default settings, it seems. I could try to restore the original settings after eac3to has run through. Would that solve the problem? Or how else would you want to have the problem solved?

I am using eac3to to recode DTS or EAC3 and then tsmuxer to mux to m2ts and then to Handbrake. Handbrake no longer crashes, but handbrake sees the video as 2x the length it should be. If I open the bluray stream direct, I don't have the problem, but I can't read the audio. I have a small EVO file, 65 megs, unilogo.evo, that I use to test, and eac3to 3.03 doesn't seem to work with it. I can upload the file somewhere if you like.
I don't even know Handbrake, and I can't tell you where the problem is exactly. You should try to find out which of the software involved is guilty for the problem. Is it eac3to? I doubt it, but if you see any indication for that, just let me know.

I have a raw h264 stream that was encoded using x264 with the following avs script:

DirectShowSource("C:\Personal\Videos\sample.mkv", fps=23.976, audio=false)
Spline64Resize(1280,720)

When I take the raw h264 and mux to mkv using eac3to v3.03 it is reported as 23 fps.
eac3to only accepts "24000/1001" as "24". If you use "23976/1000" that is displayed as "23". You should try encoding the h264 stream as "24000/1001" instead of 23.976. I can't really tell you how to do that, though, since I never used x264 myself yet...

Could you please add force writting framerate information to such streams?
Maybe.

Lowering volume is not an option, at least for me.
Well, lowering the volume is the ONLY option you have if there is clipping.

How exactly elimination of clipping works?
Volume is lowered by exactly the amount that is necessary to have no clipping, anymore.

If in "eac3to" there will be write buffers for output files, then how big they must be to avoid 2nd pass running?
The whole audio file! :)

Is it possible to implement possibility to use ANY values for this switches? Then your tool will be ULTIMATE for resampling purposes. :)
P.S. Is "/" symbol present there by mistake?
No, it's not possible, because the SSRC resampling library does not support "any" values. The "/..." in the help means that "23.976" is not the only supported value.

Just demuxed dark knight blu ray (UK), using hd stream extractor. Video demuxed fine to mkv, audio saved as .thd (not THD+AC3). The resulting audio file is not accepted in tsmuxer,tsremux, or mkvmerge.
mkvmerge does not support TrueHD at all. tsMuxeR only supports "TrueHD+AC3", and even that only buggy. Don't know about TsRemux.

shambles

13th January 2009, 20:35

I have a raw h264 stream that was encoded using x264 with the following avs script:

DirectShowSource("C:\Personal\Videos\sample.mkv", fps=23.976, audio=false)
Spline64Resize(1280,720)

When I take the raw h264 and mux to mkv using eac3to v3.03 it is reported as 23 fps.

eac3to only accepts "24000/1001" as "24". If you use "23976/1000" that is displayed as "23". You should try encoding the h264 stream as "24000/1001" instead of 23.976. I can't really tell you how to do that, though, since I never used x264 myself yet...

adding 'assumefps(24000,1001)' into the avs script gives exact 24000/1001 output

n0mag!c

13th January 2009, 21:19

How exactly elimination of clipping works?Volume is lowered by exactly the amount that is necessary to have no clipping, anymore.
If in "eac3to" there will be write buffers for output files, then how big they must be to avoid 2nd pass running?
The whole audio file!
Is this means that volume is lowered for whole audio file??? I guessed not!

laserfan

13th January 2009, 21:26

I have a raw h264 stream that was encoded using x264 with the following avs script:

DirectShowSource("C:\Personal\Videos\sample.mkv", fps=23.976, audio=false)
Spline64Resize(1280,720)

...eac3to only accepts "24000/1001" as "24". If you use "23976/1000" that is displayed as "23". You should try encoding the h264 stream as "24000/1001" instead of 23.976. I can't really tell you how to do that, though, since I never used x264 myself yet...

adding 'assumefps(24000,1001)' into the avs script gives exact 24000/1001 output

I'm confused. Can someone explain the difference between:

1. Using the --24000/... option in eac3to vs.

2. the fps= option of DSS e.g. DirectShowSource(clip, fps=23.0976) vs.

3. assumefps e.g

DirectShowSource(clip)
AssumeFPS(24000,1001)

If the original raw h264 file contains info that IDs its framerate, do you need ANY of these 1, 2 or 3 when demuxing with eac3to and then re-encoding with x264? :confused:

n0mag!c

13th January 2009, 21:40

If the original raw h264 file contains info that IDs its framerate, do you need ANY of these 1, 2 or 3 when demuxing with eac3to and then re-encoding with x264? :confused:
Some manipulations will be needed only when muxing (to mkv) with eac3to.
When muxing with tsMuxer then better check "change fps".

n0mag!c

13th January 2009, 21:45

When I take the raw h264 and mux to mkv using eac3to v3.03 it is reported as 23 fps.
You can use "demux" option in tsMuxer (yes, with raw stream), check "change fps" option with "24000/1001" and get another stream, which "eac3to" will suppose 24p.

Jeff Flowerday

13th January 2009, 21:59

madshi

13th January 2009, 22:15

Is this means that volume is lowered for whole audio file???
Of course it is!

If the original raw h264 file contains info that IDs its framerate, do you need ANY of these 1, 2 or 3 when demuxing with eac3to and then re-encoding with x264? :confused:
This is not really the right thread to ask about how to reencode with x264. I can't help you with that at all.

asarian

14th January 2009, 00:39

Well, lowering the volume is the ONLY option you have if there is clipping.

Pardon my ignorance in the matter, but I take it clipping is the result of a decoder chopping off data above a certain volume threshold? (Probably according to Dolby specs). So, does this happen in your amp? Or already in, say, the Arcsoft DTS decoder? (as in, effectively, losing data).

It just seems hard to imagine tracks would be released that an official decoder can't decode properly without having to chop off data.

Chumbo

14th January 2009, 00:41

This is slightly problematic. eac3to uses colored output now. By doing so I have to overwrite the default settings, it seems. I could try to restore the original settings after eac3to has run through. Would that solve the problem? Or how else would you want to have the problem solved?

Restoring it would be nice as I can live with it being different during the execution. ;) I'm curious though, can you not get that info prior and just use the defaults for the session? What about the background, i.e., is there a setting that allows you to use something like transparent? Any how, no big deal, restoring it would be great. :) Thank you.

KevinMcPool

14th January 2009, 00:42

:thanks: for the update which (of course :D ) fixes the dtshd to lpcm conversion in seamless branching titles and produces a log file :D

laserfan

14th January 2009, 00:50

This is not really the right thread to ask about how to reencode with x264. I can't help you with that at all.Ok, there's nothing in the help file, and no readme with this program, so I had to search this thread to find out what your -fps option is really FOR:

Let me explain the new FPS changing options:

(1) If you have a source which contains FPS information, you don't need to tell eac3to which FPS the source has. E.g. if you feed eac3to a m2ts, TS, EVO or VOB file with a video track in it, eac3to will know which FPS the video and audio tracks have. So in this case you can just use "-slowdown" to convert both 24.000 and 25.000 movies to 23.976 fps. Or you can use "-speedup" to convert both 23.976 and 24.000 movies to 25.000 fps.

(2) If eac3to does not know the source FPS (which is usually the case if you feed eac3to with a demuxed audio track), you can still use the "-slowdown" and "-speedup" options. If you do that, eac3to will apply 25.000 -> 23.976 (slowdown) or 23.976 -> 25.000 (speedup) conversion.

(3) If you want to do any funny conversions. E.g. if you want to convert a 25.000 source to 24.000, you can use the option "-changeTo24.000". If eac3to knows the source FPS, that's all you need to do. If eac3to doesn't know the source FPS, you should do "-25.000 -changeTo24.000" to do a 25.000 -> 24.000 conversion.

(4) Generally, if the source is a container which contains both video and audio tracks, doing either "eac3to source -demux -anyFpsChangeOptions" or "eac3to source some.mkv -anyFpsChangeOptions" will result in eac3to doing FPS conversion for all audio and video tracks. Audio tracks will be transcoded in this situation. Lossless tracks will be transcoded to 24bit FLAC. Lossy tracks will be transcoded to 640kbps AC3.

(5) Video FPS changes will as usual not only result in adjusted MKV timestamps. eac3to will also automatically adjust the video bitstream itself to reflect the FPS value change.
So, at least wrt the fps options of eac3to, the ONLY TIME one needs to use the -23.976 is when the source file contains no fps information, and you want to CHANGE the frame rate. Correct?

I still don't understand your answer to rack04--I might've guessed it would just be "yes 23 is correct for your encoding".

shanghai2004

14th January 2009, 03:57

Madshi,

With v3.03 found minor issue with the handling of audio gaps/overlaps in EAC3 audio tracks.

1: h264/AVC, 1080i60 /1.001 (16:9)
2: E-AC3, 5.1 channels, 3024kbps, 48khz, -67ms
3: E-AC3, 2.0 channels, 448kbps, 48khz, -67ms
4: Subtitle (VobSub)

When giving just the command eac3to c:\movie e:\movie.mkv, normally, eac3to will process all audio tracks as well. The audio is output as .EAC3 files.

When there is a gap or overlap detected, eac3to wants to do a 2nd pass to correct the audio. This fails because eac3to seems not able to process gaps in EAC3 files.

This works properly (including 2nd pass):
eac3to c:\movie 1: e:\movie_v.mkv 2: movie_6ch.flac

madshi

14th January 2009, 07:53

Pardon my ignorance in the matter, but I take it clipping is the result of a decoder chopping off data above a certain volume threshold? (Probably according to Dolby specs). So, does this happen in your amp? Or already in, say, the Arcsoft DTS decoder? (as in, effectively, losing data).

It just seems hard to imagine tracks would be released that an official decoder can't decode properly without having to chop off data.
Clipping means that the audio data gets over a specific threshold somewhere during its runtime. When that happens, the resulting audio file would either be invalid, or it the audio samples which are too "high" would have to be shortened ("clipped"). This mostly happens if you do processing. E.g. if you do "-slowdown", clipping can happen sometimes. The decoders themselves usually do not output clipped results. The ArcSoft/Nero decoders output integer samples, where clipping is not really possible technically. The libav decoders outputs floating point where clipping is possible. I have seen clipping from the libav decoders, but I think that's probably because it's not an "official" decoder and probably has output with too high volume. Anyway, eac3to can now fix clipping without any negative side effects.

Restoring it would be nice as I can live with it being different during the execution. ;) I'm curious though, can you not get that info prior and just use the defaults for the session? What about the background, i.e., is there a setting that allows you to use something like transparent?
Ok, so what if you configured your DOS box to show black font and white background? If I then wanted to draw white text on a transparent background, it would be invisible. You see, I can't use your defaults and then try multi-colored text output, because the number of colors possible is very limited and there'd be high danger of me accidently using a color which is invisible on your specific background color. That's why I have to redo the whole color scheme. Or I could think of a specific set of foreground colors for every possible background color you could have possibly specified. But I won't go there...

When there is a gap or overlap detected, eac3to wants to do a 2nd pass to correct the audio. This fails because eac3to seems not able to process gaps in EAC3 files.
eac3to should be able to fix gaps/overlaps in E-AC3 files just fine. Please post your full log.

shanghai2004

14th January 2009, 08:28

eac3to should be able to fix gaps/overlaps in E-AC3 files just fine. Please post your full log.

No problem...

eac3to v3.03
command line: c:\eac3to\eac3to hv001t01.evo+hv001t02.evo+hv001t03.evo+hv001t04.evo+hv001t05.evo+hv001t06.evo+
hv001t07.evo+hv001t08.evo+hv001t09.evo+hv001t10.evo+hv001t11.evo+hv001t12.evo+
hv001t13.evo+hv001t14.evo+hv001t15.evo+hv001t16.evo+hv001t17.evo+hv001t18.evo+
hv001t19.evo+hv001t20.evo+hv001t21.evo+hv001t22.evo+hv001t23.evo+hv001t24.evo+
hv001t25.evo+hv001t26.evo e:\chicago.mkv
------------------------------------------------------------------------------
EVO, 1 video track, 2 audio tracks, 1 subtitle track, 14:47:35
1: Joined EVO file
2: h264/AVC, 1080i60 /1.001 (16:9)
3: E-AC3, 5.1 channels, 3024kbps, 48khz, -67ms
4: E-AC3, 2.0 channels, 448kbps, 48khz, -67ms
5: Subtitle (VobSub)
[v02] Extracting video track number 2...
[a03] Extracting audio track number 3...
[a03] Applying (E-)AC3 delay...
[a04] Extracting audio track number 4...
[a04] Applying (E-)AC3 delay...
[v02] Muxing video to Matroska...
[a03] Creating file "e:\chicago - 3 - E-AC3, 5.1 channels, 3024kbps, 48khz.eac3"...
[a04] Creating file "e:\chicago - 4 - E-AC3, 2.0 channels, 448kbps, 48khz.eac3"...
[s05] Extracting subtitle track number 5...
[s05] Creating file "e:\chicago - 5 - Subtitle (VobSub).sup"...
[a03] Audio overlaps for 62ms at playtime 1:19:21. <WARNING>
[a04] Audio overlaps for 100ms at playtime 1:19:21. <WARNING>
[a03] Starting 2nd pass...
[a03] Creating silent AC3 frame failed. <WARNING>
[a03] Realizing (E-)AC3 gaps...
[a03] Creating file "e:\chicago - 3 - E-AC3, 5.1 channels, 3024kbps, 48khz.eac3"...
[a04] Starting 2nd pass...
[a04] Creating silent AC3 frame failed. <WARNING>
[a04] Realizing (E-)AC3 gaps...
[a04] Creating file "e:\chicago - 4 - E-AC3, 2.0 channels, 448kbps, 48khz.eac3"...
Added fps value to MKV header.
eac3to processing took 39 minutes, 39 seconds.
Done.

The 2nd pass took less then a second, so was not done properly probably.

asarian

14th January 2009, 08:34

Clipping means that the audio data gets over a specific threshold somewhere during its runtime. When that happens, the resulting audio file would either be invalid, or it the audio samples which are too "high" would have to be shortened ("clipped"). This mostly happens if you do processing. E.g. if you do "-slowdown", clipping can happen sometimes. The decoders themselves usually do not output clipped results. The ArcSoft/Nero decoders output integer samples, where clipping is not really possible technically. The libav decoders outputs floating point where clipping is possible. I have seen clipping from the libav decoders, but I think that's probably because it's not an "official" decoder and probably has output with too high volume. Anyway, eac3to can now fix clipping without any negative side effects.

Thanks for the in-depth explanation. Much appreciated. :)

ragboy

14th January 2009, 08:53

I have a quick question. When I check a title, it shows the audio delay of a track, like say (7ms). When I transcode to AC3, it says it is applying the RAW/LPCM delay. Does this mean that I don't need to appy that 7ms when remuxing? Does eac3to apply that delay on transcoding, so I don't need to adjust when I mux?

madshi

14th January 2009, 10:25

[a03] Creating silent AC3 frame failed. <WARNING>
That's a bug, but it has no negative effect.

[a03] Realizing (E-)AC3 gaps...
[a03] Creating file "e:\chicago - 3 - E-AC3, 5.1 channels, 3024kbps, 48khz.eac3"...
[a04] Starting 2nd pass...
[a04] Creating silent AC3 frame failed. <WARNING>
[a04] Realizing (E-)AC3 gaps...
[a04] Creating file "e:\chicago - 4 - E-AC3, 2.0 channels, 448kbps, 48khz.eac3"...
Added fps value to MKV header.
eac3to processing took 39 minutes, 39 seconds.
Done.

The 2nd pass took less then a second, so was not done properly probably.
2nd pass processing can be very fast, depending on the circumstances. If eac3to says 2nd pass processing succeeded, then it most probably did.

I have a quick question. When I check a title, it shows the audio delay of a track, like say (7ms). When I transcode to AC3, it says it is applying the RAW/LPCM delay. Does this mean that I don't need to appy that 7ms when remuxing? Does eac3to apply that delay on transcoding, so I don't need to adjust when I mux?
That's right. eac3to already applies the delay for you. Generally when using eac3to you usually don't need to worry about delays. The only exception is when eac3to creates a file for you with "DELAY" in the file name. In that case eac3to was not able to apply the delay. But the usually only happens for TrueHD tracks.

rack04

14th January 2009, 15:44

When muxing raw h264 stream to mkv using eac3to it doesn't appear to include the "muxing mode" information in the container. Verified using mediainfo. I understand this isn't anything important, just thought I'd pass it along.

For example:

Raw h264 stream to mkv using mkvmerge:

Video
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 3 frames
Muxing mode : Container profile=Unknown@4.1
Codec ID : V_MPEG4/ISO/AVC
Duration : 1mn 59s
Bit rate : 3 182 Kbps
Nominal bit rate : 3 324 Kbps
Width : 1 280 pixels
Height : 688 pixels
Display aspect ratio : 1.860
Frame rate : 23.976 fps
Resolution : 24 bits
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 0.151
Writing library : x264 core 65 r1074M b6bb3d4

Raw h264 stream to mkv using eac3to:

Video
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 3 frames
Muxing mode : Container profile=Unknown@0.0
Codec ID : V_MPEG4/ISO/AVC
Duration : 1mn 59s
Bit rate : 3 181 Kbps
Nominal bit rate : 3 324 Kbps
Width : 1 280 pixels
Height : 688 pixels
Display aspect ratio : 1.860
Frame rate : 23.976 fps
Resolution : 24 bits
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 0.151
Writing library : x264 core 65 r1074M b6bb3d4

Nullity

14th January 2009, 15:45

That's right. eac3to already applies the delay for you. Generally when using eac3to you usually don't need to worry about delays. The only exception is when eac3to creates a file for you with "DELAY" in the file name. In that case eac3to was not able to apply the delay. But the usually only happens for TrueHD tracks.

But I thought eac3to could only apply delays in 32ms frames or "chunks"? So if his source audio stream had a delay of say +/- 7ms, what operation would be performed on that stream exactly? Would it not touch it, since 7ms is close to no delay, maybe only if it was +7? If -7, would it apply +32ms resulting in a final delay of +25ms? Are different audio types handled differently?

I have an HDDVD with an EAC3 track that has a delay of -1001ms. When I processed it (which was a few months ago, so an older version of eac3to, don't remember which), it said it took care of the delay, yet there is still a delay, just not -1001ms. I have not been able to tell exactly how much, but through trial and error, I have narrowed it down to somewhere around 100ms.

Could you please add a feature which always adds the correct delay amount to either the file name and/or the log, regardless of if it was processed or not? Even if eac3to was able to process the file correctly to a 0ms delay, that would still be helpful to see.

rebkell

14th January 2009, 15:51

But I thought eac3to could only apply delays in 32ms frames or "chunks"? So if his source audio stream had a delay of say +/- 7ms, what operation would be performed on that stream exactly? Would it not touch it, since 7ms is close to no delay, maybe only if it was +7? If -7, would it apply +32ms resulting in a final delay of +25ms? Are different audio types handled differently?

I have an HDDVD with an EAC3 track that has a delay of -1001ms. When I processed it (which was a few months ago, so an older version of eac3to, don't remember which), it said it took care of the delay, yet there is still a delay, just not -1001ms. I have not been able to tell exactly how much, but through trial and error, I have narrowed it down to somewhere around 100ms.

Could you please add a feature which always adds the correct delay amount to either the file name and/or the log, regardless of if it was processed or not? Even if eac3to was able to process the file correctly to a 0ms delay, that would still be helpful to see.

32ms is the length of an AC3 sample @48KHz, the various audio samples vary in length, 48KHz aac is 21.3333ms in length, Madshi can tell you the others, a lot of them are in the thread somewhere. The delay will be gotten as close as is possible to the nearest sample size.

I think I read somewhere that about 16ms is as close as anyone can determine a/v sync, could be even bigger, anyone know what the number is?

Chumbo

14th January 2009, 15:57

Ok, so what if you configured your DOS box to show black font and white background? If I then wanted to draw white text on a transparent background, it would be invisible. You see, I can't use your defaults and then try multi-colored text output, because the number of colors possible is very limited and there'd be high danger of me accidently using a color which is invisible on your specific background color. That's why I have to redo the whole color scheme. Or I could think of a specific set of foreground colors for every possible background color you could have possibly specified. But I won't go there...

Yep, that's pretty much a given, i.e., that your colors may not match what a user may have configured, but it's the deal in the DOS world. I understand that I may need to change them if you go that route which is why if you just reset after eac3to runs, that should be fine...and less of a headache for you. ;)

madshi

14th January 2009, 16:08

When muxing raw h264 stream to mkv using eac3to it doesn't appear to include the "muxing mode" information in the container. Verified using mediainfo. I understand this isn't anything important, just thought I'd pass it along.
I have no control over that, I think. I'm using Haali's Matroska Muxer to do the muxing.

But I thought eac3to could only apply delays in 32ms frames or "chunks"? So if his source audio stream had a delay of say +/- 7ms, what operation would be performed on that stream exactly? Would it not touch it, since 7ms is close to no delay
When doing pure AC3 demuxing, a delay of +/- 7ms would simply be ignored. No normal human could possible notice such a delay error, anyway. However, if the track is decoded, delay can be done on a per sample base, which means delay exactness can be done in "1/48" ms steps.

I have an HDDVD with an EAC3 track that has a delay of -1001ms. When I processed it (which was a few months ago, so an older version of eac3to, don't remember which), it said it took care of the delay, yet there is still a delay, just not -1001ms. I have not been able to tell exactly how much, but through trial and error, I have narrowed it down to somewhere around 100ms.
There's no way on earth eac3to would leave 100ms delay in the stream without telling you. I'd guess that either the HD DVD was authored badly, or that for whatever reason eac3to calculated a slightly incorrect delay value. Timestamps in HD DVD are less exact as with Blu-Ray, so it's more or a guess in HD DVD handling compared to Blu-Ray.

Could you please add a feature which always adds the correct delay amount to either the file name and/or the log, regardless of if it was processed or not? Even if eac3to was able to process the file correctly to a 0ms delay, that would still be helpful to see.
IMO the file names are long enough as they are. Also I don't want to get people confused. I can already see getting flooded with questions like "do I have to take care about the delay now or not?" and "how can I get rid of those remaining 7ms delay?" etc. No thanks...

I think I read somewhere that about 16ms is as close as anyone can determine a/v sync
Technically with Blu-Ray at least you can calculate delay very exactly, better than 1ms. But whether the studio really authored the disc that well is another question. I often notice that when I compare English vs. German audio tracks in a WAV editor, that they don't match exactly in sync. There are often a few ms difference (*not* caused by eac3to).

A normal human can see a delay mismatch of maybe 30-50ms if he's really good. Many people only see a mismatch of 100ms or bigger.

The best eac3to can do with bitstream audio is half an audio frame, which in the worst case is a raster of 16ms correction for AC3 tracks. All other audio tracks have smaller audio frames than that. So 16ms mismatch is worst case. And as I said, if you ask eac3to to decode/transcode audio, delay can be corrected in 1/48 ms steps.

Yep, that's pretty much a given, i.e., that your colors may not match what a user may have configured, but it's the deal in the DOS world. I understand that I may need to change them if you go that route which is why if you just reset after eac3to runs, that should be fine...and less of a headache for you. ;)
Ok, will see if I can make that work...

Nullity

14th January 2009, 16:48

IMO the file names are long enough as they are. Also I don't want to get people confused. I can already see getting flooded with questions like "do I have to take care about the delay now or not?" and "how can I get rid of those remaining 7ms delay?" etc. No thanks...

Fair enough, but could you please add the remaining delay to the log output? For instance, if my source AC3 stream has a delay of -112ms, and eac3to corrects it to -16ms (+3 32ms frames), could that be added to the log somewhere so I know what value to use when I remux the streams? That would be extremely helpful. I, and probably most people, do not know the frame size of all stream types, so doing the math ourselves is not really feasible. In my example case, I know a -16ms delay is not much and might not even be detectable, but it would be beneficial to know this information. eac3to already has to do the calculations, I would think it would be incredibly easy to just append that value to the log output. Even if you have to add a little note next to it saying "It is not necessary to correct a delay less than XXms" so you don't get a bunch of questions.

A normal human can see a delay mismatch of maybe 30-50ms if he's really good. Many people only see a mismatch of 100ms or bigger.

I am one of those people who are extremely sensitive to audio delays.