eac3to - audio conversion tool

[tebasuna51]

Originally Posted by nautilus7

So, is there anything i can do? Can i fix the header?

Like Madshi say you can use a hex editor (WinHex or the free HxD) to try to correct them.

With your sample you can correct the problem if you:

1) Open test.eac3 in HxD and go to Offset(d) 2840576 (or Offset(h) 2B5800). The offset is (Frame reported by DelayCut -1) * FrameSize = (2775 - 1) * 1024 = 2840576

2) Replace the values in the sample: DB 00 0A D0
by the correct values: 0B 77 01 FF
and save the file.

3) Now you can check test.eac3 with DelayCut with no errors, then the CRC are ok.

@madshi

I've extracted the PCM from POTC3 with xport (-h) and used the -bluray switch to convert it to WAVs. The channel mapping in the end is correct. But shouldn't it be messed up now according to your explanation?

[menlvd]

i try to reencode ddp track with -libav option and get bad sound
but when reencode with nero have a normal sound
I'll upload short cut off resulting file

2 minutes

[MichalHabart]

Originally Posted by madshi

Good question. I should have explained it.

eac3to doesn't really know (and has no way to find out) in which order the channels are, if you feed it with a RAW or PCM file. The previous eac3to version made it simple: RAW input files were not supported. Only PCM files (files with the extension "pcm") were supported. Basically eac3to interpreted any PCM file input as being Blu-Ray and thus automatically remapped the channels accordingly.

But now the new eac3to version supports both PCM and RAW files (which are really one and the same). It's impossible to know whether the file came from Blu-Ray or not. So it's also impossible to know whether the channels need to be remapped or not. eac3to v2.x now does an educated guess: PCM tracks from Blu-Ray are usually big endian. RAW tracks decoded from any DirectShow (or other) decoder are usually little endian. So eac3to v2.x handles big endian RAW/PCM files as coming from Blu-Ray and little endian RAW/PCM files as not coming from Blu-Ray. As a result channels are remapped according to Blu-Ray specs when the source file is big endian. And channels are NOT remapped at all when the source file is little endian. If the channels are remapped eac3to v2.x sais so (something like "this is probably a Blu-Ray PCM file, so I'll remap the channels").

If you demux Blu-Ray (L)PCM tracks with either xport or TsRemux the demuxed files will be big endian. In this case you don't need to tell eac3to anything. Just call it as usual with "eac3to source.pcm dest.whatever" and the channels will be automatically remapped correctly. However, if you demux Blu-Ray (L)PCM tracks by using GraphEdit -> SomeSplitter -> Dump, the resulting file will be little endian. As a result eac3to will think that this file is not coming from Blu-Ray. In this case you can use the reintroduced switch "-blu-ray" to force eac3to to remap the channels. But you need to be cautious: The DirectShow splitter might already have remapped the channels - or not.

Short version: If you use xport or TsRemux for demuxing Blu-Ray (L)PCM tracks, you don't need the "-blu-ray" switch. eac3to v2.x will still automatically remap the channels correctly for you.

Thank you for very good explanation.

[nautilus7]

Originally Posted by madshi

Well, you could check the frame size (in bytes) in delaycut. Then with a hex editor you can search for the frame where the first two bytes of the frame are not correct and manually correct them. Of course this only works if the "garbage" in your track is exactly one frame long. If it's real added garbage, it'd be better to skip that data. If it's not real garbage, but just a corrupted frame then it might be better to silence the frame.

I believe the garbage is 1 frame long only, 2 frames with problem. Silence doesn't work and the frames are always skipped as you told me before because they are not valid.

Originally Posted by tebasuna51

Like Madshi say you can use a hex editor (WinHex or the free HxD) to try to correct them.

With your sample you can correct the problem if you:

1) Open test.eac3 in HxD and go to Offset(d) 2840576 (or Offset(h) 2B5800). The offset is (Frame reported by DelayCut -1) * FrameSize = (2775 - 1) * 1024 = 2840576

2) Replace the values in the sample: DB 00 0A D0
by the correct values: 0B 77 01 FF
and save the file.

3) Now you can check test.eac3 with DelayCut with no errors, then the CRC are ok.

The correct value for the frame header is the same for every frame? I mean do i put the same value for the other bad frame in the track?

I 'll try it and report back. Hope it works!

EDIT: I corrected the 2 frames and now eac3to seems to accept the track properly! Thank you both very much!

[madshi]

Originally Posted by honai

I've extracted the PCM from POTC3 with xport (-h) and used the -bluray switch to convert it to WAVs. The channel mapping in the end is correct. But shouldn't it be messed up now according to your explanation?

No, why? "xport"ed PCM tracks are big endian. So eac3to enabled the "-blu-ray" switch automatically. You manually enabled that switch, too, which had no effect, since it was already automatically enabled by eac3to.

[madshi]

Originally Posted by menlvd

i try to reencode ddp track with -libav option and get bad sound

I'm not in a position to fix the sound. Have you read what I wrote in the eac3to v2.05 release notes?

The libav E-AC3 decoder is not useable yet IMHO. It sometimes gives out distorted sound for me. I've still enabled it so that you can play with it, if you like.

No, why?

It seemed from your first explanation that the -blu-ray switch also forcefully remaps channels (in which case it'd have messed up the order because it was correct to start with). Obviously that's not the case.

[madshi]

Originally Posted by honai

It seemed from your first explanation that the -blu-ray switch also forcefully remaps channels (in which case it'd have messed up the order because it was correct to start with). Obviously that's not the case.

No, the order was not correct to start with. It needed to be corrected. But of course eac3to is not that stupid that it executes the Blu-Ray channel remapping twice on the same data...

Hmm. How exactly does eac3to determine the channel order in the source PCM? By some heuristic on the presumed LFE channel? Or is -blu-ray always enabled for all .pcm content? This is really confusing.

[madshi]

Originally Posted by honai

Hmm. How exactly does eac3to determine the channel order in the source PCM? By some heuristic on the presumed LFE channel? Or is -blu-ray always enabled for all .pcm content? This is really confusing.

Please read my very long explanation I posted as a reply to MichalHabart's question. It explains what happens fairly extensively. Basically "-blu-ray" is automatically enabled for big endian raw/pcm files.

I did that, and from what I've read so far it seems that eac3to will remap channels if the source is big-endian, regardless of the actual channel order. Which means that if the source PCM happens to be big-endian but already has the correct channel order, eac3to will mess it up implicitly. I don't think that's desirable behavior. The endianness and channel ordering should be decoupled.

This is all assuming that you still want to develop eac3to as a general audio tool, in which case the above educated guesses about the format of the source could very well be wrong for a great number of audio sources.

Concrete suggestion: Change the "-blu-ray" option into "-xport" (or something to that effect) to indicate that the source is from xport and is big-endian *and* has Blu-ray channel order.

[madshi]

Originally Posted by honai

I did that, and from what I've read so far it seems that eac3to will remap channels if the source is big-endian, regardless of the actual channel order. Which means that if the source PCM happens to be big-endian but already has the correct channel order, eac3to will mess it up implicitly. I don't think that's desirable behavior. The endianness and channel ordering should be decoupled.

This is all assuming that you still want to develop eac3to as a general audio tool, in which case the above educated guesses about the format of the source could very well be wrong for a great number of audio sources.

Concrete suggestion: Change the "-blu-ray" option into "-xport" (or something to that effect) to indicate that the source is from xport and is big-endian *and* has Blu-ray channel order.

Well, I respect your point of view, but mine happens to differ. eac3to was written mainly as a tool for HD DVD and Blu-Ray tracks. Ok, it does more than that right now, but the primary focus is still to make converting HD DVD and Blu-Ray tracks as easy as possible. I don't want people to remember having to add a "-blu-ray" or "-xport" switch everytime they convert a Blu-Ray (L)PCM track.

Please name a few multichannel sources which are big endian and do *not* have the Blu-Ray channel ordering. Are there any? I'm not aware of any such sources. Because of that I don't think there's any danger in automatically activating the "-blu-ray" switch for big endian PCM files. You can try to convince me otherwise, but you'll need good arguments... E.g. it would help if you could say where a big endian PCM track with WAV channel order could come from.

Of course you can force eac3to to not remap channels by overwriting the channel mapping matrix (e.g. "eac3to source.pcm dest.whatever -0,1,2,3,4,5").

[Thunderbolt8]

Originally Posted by madshi

According to the real data inside.

ok, is this now 100% sure? or could it be because maybe there wasnt any data for the other 2 channels in that sample I gave = would it help if I provided another sample?

[madshi]

Originally Posted by Thunderbolt8

ok, is this now 100% sure? or could it be because maybe there wasnt any data for the other 2 channels in that sample I gave = would it help if I provided another sample?

It's 100% sure, as far as I can say.

Besides, I've searched and didn't find a single HD DVD or Blu-Ray disc with a 7.1 TrueHD. It seems such a disc doesn't exist yet. I also didn't find any disc with a 7.1 E-AC3 track.

[Thunderbolt8]

good, then trueHd decoding seems to be complete

[Snowknight26]

So I tried converting the Poseidon TrueHD track (24bit) to DTS and FLAC, but I noticed different lengths. I then compared it to my previous conversions, and the DTS length was different yet again.

eac3to v2.05:
DTS, 5.1 channels, 1:38:44, 24 bits, 1536kbit/s, 48khz
FLAC, 5.1 channels, 1:38:13, 16 bits, 48khz (-down16 was used)

eac3to v1.23:
DTS, 5.1 channels, 1:40:18, 24 bits, 1536kbit/s, 48khz
FLAC, 5.1 channels, 1:38:13, 16 bits, 48khz (-down16 was used)

How do I know which one is the proper one (if any), and why do the DTS transcodes have varying length?

Edit:
I also compared a different DD+ track to various encodes. Source is "E-AC3, 5.1 channels, 1:47:35, 1536kbit/s, 48khz, dialnorm: -27dB" according to eac3to v2.05. Then just for the heck of it, I converted that to AC3 using v2.05.

eac3to v2.05:
DTS, 5.1 channels, 1:48:09, 24 bits, 1536kbit/s, 48khz
AC3, 5.1 channels, 1:47:35, 640kbit/s, 48khz

eac3to v1.23:
DTS, 5.1 channels, 1:49:52, 24 bits, 1536kbit/s, 48khz

:\

[Thunderbolt8]

a question regarding that trueHD syncing, could it be possible that the track (flac from truehd) is always in sync now, even if evodemux states a delay for it regarding different first pts?
im trying to remux batman begins and according to evodemux the track should need -200ms of delay. but frankly said some scenes are like this and some (actually most) fit better without that -200. thats why Im asking if with that sync fix something like this could have happened as (unintended?) side effect. or could it possibly be that the delay is different for the 1st and 2nd evo in this special case? some situations definately look a bit differently regarding sync compared to playback of the disc with powerdvd.

Opening file PEVOB_1.EVO
Reading...
File size: 11205 Mbytes.
VOB number 4 contains 2 video , 5 audio and 4 subpicture streams.
PTM of first video frame = 00000D61
PTM of last video frame = 19B28220
Duration = 1:19:50.286
VC-1 video stream 0 found!
   First PTS = 00000D61
Dolby TrueHD audio stream 1 found!
   First PTS = 000053C3  (+200ms)

Opening file PEVOB_2.EVO
Reading...
File size: 7732 Mbytes.
VOB number 5 contains 2 video , 5 audio and 4 subpicture streams.
PTM of first video frame = 19B28220
PTM of last video frame = 2D139A61
Duration = 1:00:12.559
VC-1 video stream 0 found!
   First PTS = 19B28220  (+4790285ms)
Dolby TrueHD audio stream 1 found!
   First PTS = 19B2659A  (+4790204ms)

ive just noticed that compared to powerdvd the playtime is 8 seconds longer, but theres no other delay specific problem other than the one I related to (meaning the delay is not off by 8 seconds). still, could it be possible that the framerate is slightly different which could result to those slight sync differences?

[Snowknight26]

I think the delay between the audio and video stream is different between the 1st and 2nd EVO. That might be causing my problems too, as the 2nd test I did had EVOs like what I just described.

According to your post:

1st EVO's delay is +200. (200-0=+200)
2nd EVO's delay is -81. (4790204-4790285=-81)

What it seems is that during the middle of the movie, the audio would be off by 119ms (or 281ms, can't think, heads spinning ).

But then again, maybe I'm totally wrong.

[Thunderbolt8]

I guess if then it would just change at once, with the beginning of the 2nd evo, but there wouldnt be nothing like an average value of both evos. I know that madshi said the value of the 2nd .evo actually dont matter. but maybe during the last updates something happened unintentionally, dont know :S or that disc is just different