eac3to - audio conversion tool

[madshi]

Trying to remux The Game Plan with eac3to:

eac3to bd-tgp
1) 00139.mpls, 2:07:03
[92+1+93+3+94+5+95+7+96+9+97+11+98+13+99+15+16+100+18+101+20+102+22+103+24+10
4+26+105+28+106+30+107+32+108+109+35+110+37+111+39+112+41+113+43+114+45+115+47+1
16+49+117+51+118+53+119+55+120+57+121+59+122+61+123+63+124+65+125+67+126+69+127+
71+128+73+129+75+130+77+78+131+80+132+82+133+84+134+86+135+88+136+90+137].m2ts
- h264/AVC, 1080p24 /1.001 (16:9)
- RAW/PCM, English, multi-channel, 48khz
- AC3, English, multi-channel, 48khz
- AC3, English, multi-channel, 48khz
- AC3, English, multi-channel, 48khz
- AC3, English, stereo, 48khz


The result is a perfect mkv of the video. But audio is screwed up. The first chunk (a few minutes) of audio is repeated several times during the first 15 minutes. The disney theme cuts in all over the place.
Is the problem reproducable with a small sample? If so, could I get that sample, please?

P.S: I guess eac3to asked you to rerun the command line to fix audio overlaps? Did you do that rerun? If so, could you please check if the problem already occurs before the rerun or if it is introduced by the overlap fixing? Thanks!

[Roscoe62]

I'm still testing, but I may have accidentally stumbled onto a solution for getting Mr & Mrs Smith to work.

It's a little left field, but it seems to have worked - I'm just muxing the files together now...will report back soon.

[rickardk]

Is the problem reproducable with a small sample? If so, could I get that sample, please?

P.S: I guess eac3to asked you to rerun the command line to fix audio overlaps? Did you do that rerun? If so, could you please check if the problem already occurs before the rerun or if it is introduced by the overlap fixing? Thanks!

Yes I did rerun before muxing audio and video. Can't produce with sample as the misplaced audio error starts 10 minutes into the movie.

Think of each letter as ~2min audio

Correct audio: a-b-c-d-e-f-g-h-i-j-k-l-m

eac3to audio: a-b-c-a-e-f-a-h-i-b-k-l-b

I will try again and check before rerun (overlap fixing)...

[sehgal.v7]

@Madshi
Sowwie, my typo mistake.. i meant, Are you planning to add option to not to demux TrueHD & AC3 seperately?
& Second was to Combine TrueHD+AC3 file that already being seperated by Eac3to?

In general term, we use Core for that AC3, that's why got confused. :-)

[Roscoe62]

OK - it's now confirmed - I can get eac3to to produce a perfectly working version of Mr & Mrs Smith, but what I had to do was a little weird.

For this particular movie, the whole movie is contained within the one m2ts file.

First off, I removed 00001.m2ts (the main file) from the stream folder in order to cut it and make Madshi a sample, but when I tested the sample, the error wasn't showing any more. I put it back into the stream folder and the error came back.

If I pointed eac3to exactly to the file within the STREAM folder (instead of just the title's folder - in this case MRMRSSMITH) no errors were displayed, but there was no option to rip the chapters either. Just on a hunch I removed EVERY OTHER m2ts file from the stream folder and put them somewhere else. Then I pointed eac3to back to the title folder (MRMRSSMITH). Eac3to produced the full list of video/audio/chapter/subtitle files without showing any error messages at all, so I let eac3to go - it produced the mkv file from the h264 video, the flac file from the DTS MA, the chapters file & the english sup file (I usually do this just in case it's a "forced subs" track) and it went all the way to completion without aborting. After using MKVMerge to put the audio & chapter files back in, and testing it, it has all worked perfectly.

I don't know why eac3to was producing that particular error on this particular disk, but hopefully there's something in my explanation that Madshi might be able to use to find what the problem was.

If you need me to do any further testing, I still have all the files on the PC and will keep them there for a while.

[xkodi]

@madshi

we are talking a lot about bit-perfect transfer here when it comes to audio, but what about the same thing with video, e.g. raw h.264 stream to MKV and vice-versa?

how i test:

eac3to file.m2ts raw_1.h264

eac3to file.m2ts file.mkv
mkvextract file.mkv to raw_2.h264

mkvmerge raw_1.h264 to file2.mkv
mkvextract file2.mkv to raw_3.h264

my expectation was that raw_1.h264, raw_2.h264 and raw_3.h264 are exactly the same or at least have some small differences in headers or something, but it turns out that they are all different and when compare them with hex editor the differences are very huge.

so, why is that and is it OK?

[madshi]

Yes I did rerun before muxing audio and video. Can't produce with sample as the misplaced audio error starts 10 minutes into the movie.
eac3to will tell you the runtime of each m2ts part. This way you should be able to find out in which m2ts part the problem begins. Maybe it's directly with the start of a specific m2ts part. Or maybe it's in the middle of a specific m2ts part. Anyway, maybe you can create a working sample this way? Cutting m2ts files is rather easy. You can just delete blocks of 192 bytes from the beginning or end of a m2ts file until you get exactly what you need.

I will try again and check before rerun (overlap fixing)...
Thanks, that will be helpful.

OK - it's now confirmed - I can get eac3to to produce a perfectly working version of Mr & Mrs Smith, but what I had to do was a little weird.

For this particular movie, the whole movie is contained within the one m2ts file.

First off, I removed 00001.m2ts (the main file) from the stream folder in order to cut it and make Madshi a sample, but when I tested the sample, the error wasn't showing any more. I put it back into the stream folder and the error came back.

If I pointed eac3to exactly to the file within the STREAM folder (instead of just the title's folder - in this case MRMRSSMITH) no errors were displayed, but there was no option to rip the chapters either. Just on a hunch I removed EVERY OTHER m2ts file from the stream folder and put them somewhere else. Then I pointed eac3to back to the title folder (MRMRSSMITH). Eac3to produced the full list of video/audio/chapter/subtitle files without showing any error messages at all, so I let eac3to go - it produced the mkv file from the h264 video, the flac file from the DTS MA, the chapters file & the english sup file (I usually do this just in case it's a "forced subs" track) and it went all the way to completion without aborting. After using MKVMerge to put the audio & chapter files back in, and testing it, it has all worked perfectly.
So that means that one of the other m2ts files made problems. Most probably if you have the original unmodified folder (with which the problem occurred), eac3to tried to join two (or more) m2ts parts which didn't really belong together. So my suggestion would be to retry with the original folder. Please post the eac3to log when doing "eac3to c:\whatever\mrmrssmith 1)". I think you'll find that there are at least 2 m2ts parts listed by eac3to, or maybe even more...

we are talking a lot about bit-perfect transfer here when it comes to audio, but what about the same thing with video, e.g. raw h.264 stream to MKV and vice-versa?
With VC-1 and MPEG2 you should get bit perfection when doing what you did. With h264 not so.

how i test:

eac3to file.m2ts raw_1.h264

eac3to file.m2ts file.mkv
mkvextract file.mkv to raw_2.h264

mkvmerge raw_1.h264 to file2.mkv
mkvextract file2.mkv to raw_3.h264

my expectation was that raw_1.h264, raw_2.h264 and raw_3.h264 are exactly the same or at least have some small differences in headers or something, but it turns out that they are all different and when compare them with hex editor the differences are very huge.

so, why is that and is it OK?
The difference should not be huge. The main difference should be that all 3 muxers (eac3to, Haali and mkvmerge) remove the AUDs ("access unit delimiters") when muxing the raw h264 stream to MKV. The AUDs are "[00] 00 00 01 09 xx". Their only purpose is to serve as separaters. MKV stores each access unit separately, anyway, so separaters don't make sense with MKV.

IMHO MKV demuxers should add AUDs back into the stream. Should be rather easy. Unfortunately mkvextract doesn't do that.

[xkodi]

The difference should not be huge. The main difference should be that all 3 muxers (eac3to, Haali and mkvmerge) remove the AUDs ("access unit delimiters") when muxing the raw h264 stream to MKV. The AUDs are "[00] 00 00 01 09 xx".

the same fragment from raw_1.h264 that is 217 bytes in size, has size of 242 bytes in raw_2.h264 and 263 bytes in raw_3.h264:

raw_1.h264 (217 bytes):

http://thumbnails4.imagebam.com/1172/ebb01a11718055.gif (http://www.imagebam.com/image/ebb01a11718055)

raw_2.h264 (242 bytes):

http://thumbnails4.imagebam.com/1172/edc3cb11718060.gif (http://www.imagebam.com/image/edc3cb11718060)

raw_3.h264 (263 bytes):

http://thumbnails4.imagebam.com/1172/b2f68a11718239.gif (http://www.imagebam.com/image/b2f68a11718239)

so, we have about at least 20% difference between raw_1.h264 and raw_3.h264. it's too much, isn't it?

[madshi]

the same fragment from raw_1.h264 that is 217 bytes in size, has size of 242 bytes in raw_2.h264 and 263 bytes in raw_3.h264
Try "mkvextract --raw". raw_2 and raw_3 have the AUD stripped (as I said), but instead the sequence headers are stored twice. I think "--raw" will fix that. mkvextract sometimes prepends the codec private data to the demux when not using "--raw". This will only happen once per file, though. So it's not 50 bytes difference per frame, but per file/movie.

Generally when testing bit perfectness with video you should test more than just 200 bytes. Try 20MB at least.

[sehgal.v7]

@xKodi
Bro i spent two whole days working on mkv & h.264 & vc-1, few wks back// and i came to conclusion that once raw VC1 or H.264 went to MKV, u can NEVA get to see exact original size. No PERFECT container for timebeing.

Tools i used - VC12AVI, MKVMerge, Eac3to, Yamb, TSMuxer, TSRemux.

[xkodi]

"mkvextract --raw" and "mkvextract --fullraw" don't make any different for this particular fragment at the beginning. comparing 20MB after the fragment at the beginning shows that:

- the different between raw_1 and raw_2 is missing from time to time the following sequence:

0CFF[FF]800000000109xx00000001

which is something else + AUD.

- the different between raw_2 and raw_3 is missing from time to time the following sequence:

780A

@sehgal.v7

yes, i agree that such behavior is not what i'm expecting from container format.

[sehgal.v7]

@xKodi
Wait, i'm posting a sample in mkvtoolnix author thread, let's see thr reply.

[madshi]

i spent two whole days working on mkv & h.264 & vc-1, few wks back// and i came to conclusion that once raw VC1 or H.264 went to MKV, u can NEVA get to see exact original size. No PERFECT container for timebeing.
I disagree about VC-1.

- the different between raw_1 and raw_2 is missing from time to time the following sequence:

0CFF[FF]800000000109xx00000001

which is something else + AUD.
Are you sure about that? Can you upload those 20MB for testing purposes? The only difference should be the AUD. And eventually a stripped sequence end code.

- the different between raw_2 and raw_3 is missing from time to time the following sequence
Well, that's your own fault, if you use mkvmerge instead of eac3to... :D

I'm in contact with Mosu. He seems to consider adding AUDs to mkvextract. Maybe he'll also fix the double sequence headers at the beginning of the stream. That should give us bit perfection. Except this "something else" which we need to identify before we can talk about what to do with it.

[xkodi]

I disagree about VC-1.
VC-1 doesn't work here too. i'm doing the same test as with h264. also, will try with MPEG2.

Are you sure about that? Can you upload those 20MB for testing purposes? The only difference should be the AUD. And eventually a stripped sequence end code.

eac3to file.m2ts raw_1.h264:

http://rapidshare.de/files/40296284/raw_1_20mb.h264.html

eac3to file.m2ts file.mkv
mkvextract file.mkv to raw_2.h264:

http://rapidshare.de/files/40296287/raw_2_20mb.h264.html


Well, that's your own fault, if you use mkvmerge instead of eac3to... :D

i'm not aware of any other tool that allows me to merge the video, audio and subtitle streams together.

[edit]

eac3to file.vob raw_1.m2v:

eac3to file.vob file.mkv
mkvextract file.mkv to raw_2.m2v:

compare raw_1.m2v and raw_2.m2v:
http://img376.imageshack.us/img376/8994/m2vun8.th.jpg (http://img376.imageshack.us/my.php?image=m2vun8.jpg)

so, overall result is that currently merge/extract video to/from MKV is not bit-perfect for VC1, H264 and MPEG2.

[madshi]

VC-1 doesn't work here too.
Sample?

i'm not aware of any other tool that allows me to merge the video, audio and subtitle streams together.
You should use eac3to for muxing the video to MKV. Then you can use mkvtoolnix to add audio and subtitle streams. mkvtoolnix will not damage the video track muxed by eac3to. But if you use mkvtoolnix for muxing a raw video stream you'll have to live with results which are not as good as when using eac3to, sometimes.

eac3to file.vob raw_1.m2v
Sample?

P.S: Please use "--raw" for MPEG2 demuxing. I think at least with MPEG2 there's a big difference.

so, overall result is that currently merge/extract video to/from MKV is not bit-perfect for VC1, H264 and MPEG2.
You should not use mkvmerge + mkvextract. You should use eac3to + "mkvextract --raw". That results in bit perfect results for VC-1 and MPEG2, as far as I remember. Eventually the last video frame will be lost, but that's about it.

[sehgal.v7]

@Madshi
Test file hxxp://rapidshare.com/files/139290511/Test.ts - Demuxing them.
Original size - 9,400,000 (50000x188)

6,750,422 Video by Eac3to.h264
6,770,832 Video by TSMuxer.264
6,770,832 Video by TSRemux.h264

2,243,576 Audio by Eac3to.dtsma
2,244,847 Audio by TSMuxer.dtsma
2,244,847 Audio by TSRemux.dtsma

[madshi]

- the different between raw_1 and raw_2 is missing from time to time the following sequence:

0CFF[FF]800000000109xx00000001
That's filler data and AUD. I already explained the AUD. The filler data is just there to achieve CBR or some other stupid aims. So there's no reason to leave it in the stream. It's like zero padded DTS files. No reason really to keep it in the stream. That's why it gets removed by the MKV muxing process.

[madshi]

@Madshi
Test file hxxp://rapidshare.com/files/139290511/Test.ts - Demuxing them.
Original size - 9,400,000 (50000x188)

6,750,422 Video by Eac3to.h264
6,770,832 Video by TSMuxer.264
6,770,832 Video by TSRemux.h264

2,243,576 Audio by Eac3to.dtsma
2,244,847 Audio by TSMuxer.dtsma
2,244,847 Audio by TSRemux.dtsma
eac3to only outputs frames for which it's sure that they are complete. If eac3to cannot be sure that the last video or audio frame is complete it skips them. That's why video and audio tracks demuxed by eac3to may be one frame short compared to other demuxers. An incomplete audio or video frame could result in rainbow frames or even decoder crashes...

[xkodi]

Sample?
P.S: Please use "--raw" for MPEG2 demuxing. I think at least with MPEG2 there's a big difference.

"--raw" doesn't make any difference.

MPEG2 sample:
http://rapidshare.de/files/40296979/VTS_02_1.VOB.html

screenshot from the comparison:

http://img99.imageshack.us/img99/4500/rawm2vqr4.th.jpg (http://img99.imageshack.us/my.php?image=rawm2vqr4.jpg)

No reason really to keep it in the stream. That's why it gets removed by the MKV muxing process.

i really can't get why destroying the original stream by removing data even if they are useless. the only reason that i can think of is to save space, but with removing things like AUD you can't save space anyway.

[nautilus7]

i really can't get why destroying the original stream by removing data even if they are useless. the only reason that i can think of is to save space, but with removing things like AUD you can't save space anyway.
I don't believe that eac3to would do something harmful to our data.
And I like removing useless things from my data. I want them as clean as possible, but that's my opinion. :)

[madshi]

i really can't get why destroying the original stream by removing data even if they are useless.
Filler data is by design and by h264 specification useless for decoders. So why keep it in the stream? Removing it from the stream is in no way "destroying" the stream. It's more like "cleaning up the stream". I don't see you complaining about eac3to removing the zero padding of DTS streams. So why are you complaining about removing useless filler data from h264 streams? The only effect it has is saving space. To my best knowledge there is no other (positive or negative) effect of removing the filler data.

with removing things like AUD you can't save space anyway.
Look, with VOB and m2ts containers the video data is stored as one continuous stream of bytes. The AUDs are in the h264 streams cause they make it easier to separate frames. But MKV works very differently. It stores each frame separately. So storing the AUDs in MKV doesn't make any sense. I wouldn't even know where to store them! Should I put them in front of each frame or behind? IMO the software which demuxes a h264 stream from an MKV should put the AUDs back in. That's really easy to do. Now unfortunately Mosu doesn't seem to like the idea. But that's a different topic.

[madshi]

"--raw" doesn't make any difference.
I've tested your MPEG2 sample and I get 100% bit perfection when I use "--raw". Caution: You need to put the "--raw" parameter at the right place in the command line! Or else it will have no effect. The right command line would be this:

"mkvextract tracks sample.mkv --raw 1:test.m2v"

[xkodi]

"mkvextract tracks sample.mkv --raw 1:test.m2v"

my command was "mkvextract tracks sample.mkv 1:test.m2v --raw"

after put the "--raw" at the right place it is bit-perfect here too.

so, indeed with MPEG2 everything is OK. thank you for you help!

Filler data is by design and by h264 specification useless for decoders.

thank you for explaining this, then it is save to remove those "filler data".

what about AUDs - are decoders OK with raw h264 stream without AUDs?

[Roscoe62]

So that means that one of the other m2ts files made problems. Most probably if you have the original unmodified folder (with which the problem occurred), eac3to tried to join two (or more) m2ts parts which didn't really belong together. So my suggestion would be to retry with the original folder. Please post the eac3to log when doing "eac3to c:\whatever\mrmrssmith 1)". I think you'll find that there are at least 2 m2ts parts listed by eac3to, or maybe even more...

Well, yes and no. I posted the log already - you'll find it on the last page and it makes no mention of which m2ts files it uses.

However, when I ran the usual commands again, the step prior to that recorded in the log clearly shows that it is adding 00001.m2ts and 00002.m2ts together. Looking at the stream list the 00002.m2ts file is only 54kb in size, and is not required at all. The only thing it does is prevent eac3to from doing it's job properly.

Let me know if there's anything further I can do to help.

[madshi]

my command was "mkvextract tracks sample.mkv 1:test.m2v --raw"

after put the "--raw" at the right place it is bit-perfect here too.

so, indeed with MPEG2 everything is OK.
I hope you can confirm the same bit perfectness for VC-1?

thank you for explaining this, then it is save to remove those "filler data".
I really think so.

what about AUDs - are decoders OK with raw h264 stream without AUDs?
Decoders don't mind at all. If they minded, no h264 MKV or MP4 file would play because both containers don't store AUDs. And the default output of the x264 encoder doesn't contain any AUDs, either, as far as I know. The only containers which use AUDs by default are VOB/EVO and TS/M2TS, I believe. And I think even the VOB/EVO and TS/M2TS splitters remove the AUDs before sending the data to the decoder.

However, eac3to depends on h264 files containing AUDs. Without them eac3to doesn't properly handle h264 files. So basically if you mux a raw h264 stream to MKV, then demux it again, eac3to will not handle it properly, anymore. In the long run I need to find a way to solve this problem. Maybe I'll make eac3to not depend on AUDs, anymore. Or maybe I'll find another way. Not sure...

[madshi]

Well, yes and no. I posted the log already - you'll find it on the last page and it makes no mention of which m2ts files it uses.

However, when I ran the usual commands again, the step prior to that recorded in the log clearly shows that it is adding 00001.m2ts and 00002.m2ts together. Looking at the stream list the 00002.m2ts file is only 54kb in size, and is not required at all. The only thing it does is prevent eac3to from doing it's job properly.

Let me know if there's anything further I can do to help.
Ah, that's interesting. Can you please upload that 54kb file? Also I need a 50MB sample of 00001.m2ts again (the original upload you provided is not available, anymore, and I deleted the file already). Thanks!

[EPiPH0NE]

Well, yes and no. I posted the log already - you'll find it on the last page and it makes no mention of which m2ts files it uses.

However, when I ran the usual commands again, the step prior to that recorded in the log clearly shows that it is adding 00001.m2ts and 00002.m2ts together. Looking at the stream list the 00002.m2ts file is only 54kb in size, and is not required at all. The only thing it does is prevent eac3to from doing it's job properly.

Let me know if there's anything further I can do to help.


Yeah, once I went back in just used the main M2TS file for my source input instead of my BD-rom, Mr and Mrs Smith ran through fine. Thanks for the tip :)

[Roscoe62]

Madshi,

I've now uploaded the Mr & Mrs Smith files for you.

This (http://www.sendspace.com/file/hu2gxh) zip file has both a 50Mb sample of 00001.m2ts and also the 00002.m2ts file.

[sehgal.v7]

@Madshi
VC-1 Sample for your study, hxxp://rapidshare.com/files/139429429/Video.ts
Original TS File Size - 5,220,384
4,948,722 Demuxed Video by Eac3to.vc1
4,933,798 Extracted Video by mkvextract.vc1
4,927,251 Muxed by Eac3to.mkv
Not Exact VC1 File.

Regards,
Sehgal

[madshi]

@Madshi
VC-1 Sample for your study, hxxp://rapidshare.com/files/139429429/Video.ts
Original TS File Size - 5,220,384
4,948,722 Demuxed Video by Eac3to.vc1
4,933,798 Extracted Video by mkvextract.vc1
4,927,251 Muxed by Eac3to.mkv
Not Exact VC1 File.
As I said before, the file size alone is not a good indicator. eac3to sometimes drop the last frame which can result in a smaller file size. But that doesn't mean that bit perfection isn't reached.

[sehgal.v7]

@Madshi
First i did that on Original Blu Ray Disc, i don't think in that last frame would be incomplete. And second time for you, i did that on sample by cutting starting piece.
Secondly that mean, eac3to mux's exact stream to MKV, even if last frame is incomplete. And it only remove last incomplete frame in demuxing.

Hope, i'm getting right. And i never mean to offend you, i just want help you by testing stuff.

[madshi]

I've now uploaded the Mr & Mrs Smith files for you.
Thanks. This problem will be fixed in the next eac3to build.

First i did that on Original Blu Ray Disc, i don't think in that last frame would be incomplete. And second time for you, i did that on sample by cutting starting piece.
Secondly that mean, eac3to mux's exact stream to MKV, even if last frame is incomplete. And it only remove last incomplete frame in demuxing.
The point is that comparing the file size alone does not help. The file can reach bit perfection and still have a different file size (due to frames missing at the end). You need to compare the files with a hex editor or with a good file comparison tool to find out whether you got bit perfection or not.

[sehgal.v7]

(A)
1. Extracted 1080p24.vc1 from VC1.ts by Eac3to - (If any frame was missing, it must have been removed)
2. Made M2TS file with Scenarist. Then Extracted 1080p24.vc1 from VC1.m2ts.
------- Compared both files by Hex // both are same.

(B)
3. VC1.m2ts to VC1.mkv with Eac3to.
4. Extracted 1080p24.vc1 from VC1 by MKVExtract.
------- Compared 1080p24.vc1 (A) & 1080p24.vc1 (B) by Hex. Lotsa difference!!

Here's the Report!!
hxxp://rapidshare.com/files/139456657/Report.rar

[madshi]

(A)
1. Extracted 1080p24.vc1 from VC1.ts by Eac3to - (If any frame was missing, it must have been removed)
2. Made M2TS file with Scenarist. Then Extracted 1080p24.vc1 from VC1.m2ts.
------- Compared both files by Hex // both are same.

(B)
3. VC1.m2ts to VC1.mkv with Eac3to.
4. Extracted 1080p24.vc1 from VC1 by MKVExtract.
------- Compared 1080p24.vc1 (A) & 1080p24.vc1 (B) by Hex. Lotsa difference!!

Here's the Report!!
hxxp://rapidshare.com/files/139456657/Report.rar
I don't know exactly what you did there, but the "left" file in the comparison looks damaged to me. Look, there's even the text "mkvextract 2.2.0" in the left VC-1 file! That does not make any sense. I think you must have made a mistake somewhere...

[sehgal.v7]

@Madshi
1. eac3to VC1.ts -demux
2. eac3to VC1.m2ts -demux
3. eac3to VC1.m2ts VC1.mkv
4. mkvextract tracks VC1.mkv 1:1080p24.vc1 --raw

You can test yourself. http://rapidshare.com/files/139461876/VC1.m2ts by Scenarist.

[madshi]

4. mkvextract tracks VC1.mkv 1:1080p24.vc1 --raw
That command line is wrong. Just read the last 15 comments in this thread and you'll see why.

[sehgal.v7]

Now got it right but still at last http://rapidshare.com/files/139465417/Report_2.rar
mkvextract tracks VC1.mkv --raw 1:1080p24.vc1

[madshi]

Now got it right but still at last http://rapidshare.com/files/139465417/Report_2.rar
mkvextract tracks VC1.mkv --raw 1:1080p24.vc1
Yeah, it's exactly as I said:

The only difference between the two files is that one them has one frame missing. One of the files contains 433 frames while the other contains 432 frames. But those 432 frames are 100% bit perfectly identical.

[sehgal.v7]

@Madshi
Thanks Madshi, got every single clearance on VC1.
Jus one last ques- Are you planning to add feature to combine AC3 & TrueHD files together? :-)
Me still waiting to burn Blue Planet again ;-)

[Jan Marijniszoon]

madshi, I now found a workaround (tsMuxer combined with TsRemux) to get TrueHD tracks (with ac3-core) to work on 'homemade' Blu-rays.
I tested it myself and the TrueHD tracks plays perfectly and the core also gets recognized.

So I would like to ask you nicely when you have time for it to check out if it is possible to remove dialog normalisation from these type of tracks. How can it be done? I guess you have to find a way to remove the dialog normalisation from both the headers in the file?

[madshi]

Jus one last ques- Are you planning to add feature to combine AC3 & TrueHD files together? :-)
I already answered that question.

madshi, I now found a workaround (tsMuxer combined with TsRemux) to get TrueHD tracks (with ac3-core) to work on 'homemade' Blu-rays.
I tested it myself and the TrueHD tracks plays perfectly and the core also gets recognized.

So I would like to ask you nicely when you have time for it to check out if it is possible to remove dialog normalisation from these type of tracks. How can it be done? I guess you have to find a way to remove the dialog normalisation from both the headers in the file?
I'll add it to the to do list.

[sehgal.v7]

"I may eventually add a feature to create an interweaved TrueHD+AC3 track for Scenarist muxing."
Oki, will be waiting for that.

Secondly, i was jus experimenting with files.. If TrueHD stream contains only 16bit Information, when converting it to WAV, why it outputs 24bit??
TrueHD/AC3, 5.1 channels, 48khz, dialnorm: -27dB
Extracting TrueHD stream...
Removing dialog normalization...
Decoding with DirectShow (Nero Audio Decoder 2)...
DirectShow reports 5.1 channels, 24 bits, 48khz
Writing WAV...
Creating file "K:\Audio.wav"...
This audio track has a constant bit depth of 16 bits.
Caution: The WAV file is bigger than 2GB.
Some WAV readers might not be able to handle this file correctly.
eac3to processing took 10 minutes, 3 seconds.
Done.

LPCM or RAW wasn't accepted by Scenarist// so had to write WAV file. Is channel configuration for 6CH (L,C,R,LS,RS,lfe)??

-----
Blue Planet contains Dolby TrueHD 5.1 16-bit, how can i force eac3to to output LPCM 16-bit? Eac3to output 24-bit.

[xkodi]

i also can confirm that VC1 is bit-perfect. so, what we have till now:

- MPEG-2: bit-perfect.
- VC-1: bit-perfect, but usually the last frame is missing (at least on all test i run the last frame is always missing, anyway it's not a problem)
- H.264: AUDs and "filler data" are removed, but as madshi explained they are useless data, all other data are bit-perfect, but always have "the double sequence headers at the beginning of the stream".

[sehgal.v7]

@xKodi
Yeap, Agreed on all points!!

[madshi]

Secondly, i was jus experimenting with files.. If TrueHD stream contains only 16bit Information, when converting it to WAV, why it outputs 24bit??
That's a bug in the current version. It will be fixed in the next build.

Is channel configuration for 6CH (L,C,R,LS,RS,lfe)??
WAV channel order is L, R, C, LFE, LS, RS.

- MPEG-2: bit-perfect.
- VC-1: bit-perfect, but usually the last frame is missing (at least on all test i run the last frame is always missing, anyway it's not a problem)
Correct. You need to use "--raw" for both MPEG2 and VC-1, though, to achieve bit perfectness.

- H.264: AUDs and "filler data" are removed, but as madshi explained they are useless data, all other data are bit-perfect, but always have "the double sequence headers at the beginning of the stream".
Correct. In this case you must NOT use "--raw", btw. And I want to add that I don't consider the AUDs to be useless for a continuous stream of bytes. I just consider AUDs to be useless inside of an MKV or MP4 container. IMO an MKV/MP4 demuxer which targets to create a raw h264 file should readd AUDs. Sadly current demuxers don't do that. Maybe some day I'll have to write my own MKV demuxer. But it's not a big deal since AUDs are optional, anyway, and decoders don't need them in any case.

[sehgal.v7]

@Madshi
Thanx for fixing bug in next release.
Secondly, Scenarist is accepting L,C,R,LS,RS,lfe config for while.
Screenshot http://rapidshare.com/files/139543028/Untitled.jpg

[madshi]

Secondly, Scenarist is accepting L,C,R,LS,RS,lfe config for while.
I'm not sure but I guess that's the channel order which Scenarist will write into the final m2ts file and *not* the channel order it expects in the wav file. The wav file channel order is standardized and eac3to uses the channel order which everybody uses in wav files. Scenarist expecting a non-standard channel order in the wav file would be quite strange.

[deacon crusher]

So, I'm trying to convert CJ7 (the newish Steven Chow movie) to MKV and running into quite a bit of difficulty.

It's a multi-part (But I've dealt with that before by muxing together with tsmuxer.) However, there's some problem with the streams, when running tsmuxer or eac3to I get many alerts of the type

The program channel mapping changes in the middle of the stream.

So, I'm demuxing each seperate m2ts file using eac3to and I'm going to try to then combing together the h264 files into 1 mkv and the ac3 files into 1 ac3. However, I'd love any tips regarding correct command line options for this phase and any gotchas to look out for to make sure I'm getting rid of audio overlap and will have a final product where audio and video are in sync.

EDIT
I guess specifically my question is in madshi's quote he says audio overlap can then be fixed, how??
END EDIT

Thanks

No. The problem with m2ts multi part movies is that audio often overlaps a little. In order to fix that problem completely I would probably have to write a full featured m2ts muxer. That is not planned. With HD DVD movies it's easier because the audio doesn't overlap. So I just need to join the files and maybe correct a few timestamps. Easy. Not so with Blu-Ray.

You have 2 options:

(1) Either you can let tsMuxeR or TsRemux do the m2ts multipart joining. Neither of them will correct the audio overlaps, though. So the end result may play bumpy on the join points or eventually audio sync will gradually be lost (depends on the media player / splitter).

(2) Or you can let eac3to demux all video and audio tracks. Audio overlaps can then be fixed. Finally you can recreate a new m2ts file by using tsMuxeR or Scenarist.

[sehgal.v7]

@Madshi
Oki, i'll test and post results back!!

[scarbrtj]

Madshi:

Re: "The Bank Job" AVC/7.1 DTSHD

The AVC video track duration is 1:54:34.075

-core eac3to extraction yields a 1:52:01.749 DTS file

If I instead convert to AC3 with eac3to, we get a 1:54:34.075 file... and muxing this to the video gives perfect sync.

Obviously, a mux of the -core DTS and AVC video gives a very big video/audio sync problem.

But, I'd like to get the -core DTS and AVC together... thoughts?