Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
24th August 2008, 08:14 | #5901 | Link | |
Registered User
Join Date: Jun 2008
Posts: 1
|
Quote:
are you shure the video is 1:54:34? Im getting this: U:\BluRAY>eac3to The.Bank.Job 1) 00000.mpls, 00001.m2ts, 1:52:02 - h264/AVC, 1080p24 /1.001 (16:9) - DTS Master Audio, English, multi-channel, 48khz - AC3, French, multi-channel, 48khz - AC3, English, stereo, 48khz U:\BluRAY>eac3to The.Bank.Job 1) M2TS, 1 video track, 3 audio tracks, 3 subtitle tracks, 1:52:02 1: Chapters, 17 chapters 2: h264/AVC, 1080p24 /1.001 (16:9) 3: DTS Master Audio, English, 7.1 channels, 16 bits, 48khz 4: AC3, French, 5.1 channels, 640kbit/s, 48khz, dialnorm: -27dB 5: AC3, English, 2.0 channels, 224kbit/s, 48khz, dialnorm: -27dB 6: Subtitle (PGS), English 7: Subtitle (PGS), English 8: Subtitle (PGS), Spanish and no problems what so ever when muxing video with flac track... :edit I can see now that i have deleted all the files in the stream folder except the 00001.m2ts, maybe this is why im not having any problems... Try to use eac3to with only this file, maybe it helps.... Last edited by papaleon; 24th August 2008 at 08:26. |
|
24th August 2008, 09:36 | #5903 | Link | ||
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
Quote:
Which software are you using exactly to mux video and audio together? And into which container are you muxing them? |
||
24th August 2008, 10:45 | #5904 | Link |
Registered User
Join Date: Jul 2008
Posts: 93
|
@Madshi
Why is there difference in Dolby Digital Plus Demuxing with Eac3to AND TSRemux or TSMuxer?? (Except Last incomplete Frame?) Is it coz of Audio Delay or dialog normalization? Last edited by sehgal.v7; 24th August 2008 at 10:51. |
24th August 2008, 10:53 | #5905 | Link |
Registered User
Join Date: Jan 2006
Location: Athens, Greece
Posts: 1,518
|
Because eac3to removes Dialog Normalization by default, while others don't.
If you're worried about audio bit perfectness using eac3to and other tools, I can assure that a lot of people have test it before you. And everything is fine. |
24th August 2008, 11:28 | #5908 | Link | ||
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
Quote:
There is a difference between: (1) keeping compressed bitstream bit perfect and (2) making sure that decoded data is bit perfect. What we want above all is (2). But in order to achieve (2) we sometimes have to sacrifice (1). E.g. we have to remove dialnorm to get bit perfect audio decoding. eac3to does a lot of modifications to compressed bitstreams. Dialnorm is removed, zero padding is removed, DTS ES bitstream errors are fixed, DTS bitdepth is patched etc. All this destroys bit perfectness of the compressed bitstream, but makes sure that decoded data is bit perfect. Now the same thing is valid for video as well: eac3to does some modifictions to the compressed bitstream. E.g. pulldown is stripped, sequence end codes are removed, filler data is removed (and some more modifications to come). Some of this has a positive effect on decoding (e.g. pulldown removal can get rid of judder with some decoders), some of this just saves space (removal of filler data), but none of this has any negative effect on decoding. So that's why we shouldn't worry so much about bit perfectness of compressed bitstreams. What you should worry about is bit perfectness of decoded data. So manipulations in the compressed bitstream are ok, as long as these manipulations improve (or at least don't negatively effect) the decoding performance. This is also the reason why I was never worried about h264 bitstream not being bit perfect (see last 2 pages of discussions). Sorry for the long rant. These things just became clear to me, so I wanted to write them down to give us all a bit more piece of mind when finding differences in compressed bitstreams. Last edited by madshi; 24th August 2008 at 11:30. |
||
24th August 2008, 14:10 | #5909 | Link |
Registered User
Join Date: Mar 2008
Posts: 2,021
|
Madshi, please check mercury's file:
http://rapidshare.com/files/13962309...Test.m2ts.html This is interesting? Code:
C:\>eac3to\eac3to.exe "C:\Users\rica\Desktop\VC-1Test.m2ts" "C:\Users\rica\Desktop\new.dts" Access is denied. thanks. |
24th August 2008, 15:00 | #5912 | Link | |
Registered User
Join Date: Jul 2007
Posts: 48
|
Quote:
And @ sehgal I can see that the original 00001.m2ts file is 1:52:01. But a "funny thing happened on the way to the bank" as they say. If you take out the individual elementary AVC stream... you get a file 1:54:34 in length. I am using tsremux or tsmuxer to do that; or, if you mux into mkv with eac3to you get 1:54:34 as well. And then I used eac3to to make an AC3 from the DTS-HD track. That AC3 elementary stream is 1:54:34 in duration. When I mux the AVC and AC3 files together into M2TS... I am back to a 1:52:01 file! So, this type behavior happens for me all the time with DTS-HD files, and tsmuxer or tsremux seem no better to me at getting the timing of the -core file right. I like passing the DTS bitstream via SPDIF to my receiver, and the only way I have gotten this to work is to use MKV to wrap the DTS in. I'd love to know how other guys are getting DTS cores and playing them back via SPDIF. |
|
24th August 2008, 17:39 | #5913 | Link | |
Registered User
Join Date: Dec 2006
Posts: 523
|
Quote:
mpc-hc built in dts filter doesn't work with 1536 streams on mine and on other's setups, and spdifer at sourceforge is perfect |
|
24th August 2008, 20:01 | #5916 | Link | |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
(1) "If you take out the elementary AVC stream... you get a file 1:54:34 in length" Where did you get this runtime information from? Normally it's not possible to get a runtime information from a demuxed AVC file cause AVC is variable bitrate, so you can only guess the runtime. (2) "if you mux into mkv with eac3to you get 1:54:34 as well" If you mux what? The AVC track demuxed by TsMuxer/TsRemux? Or the m2ts file? Or did you use eac3to's Blu-Ray structure parser? In the latter case eac3to might have joined more than just m2ts parts to produce the MKV. (3) "That AC3 elementary stream is 1:54:34 in duration" Sais who? eac3to? Or your media player? I can't help you any further if you don't post more detailed reports. FWIW, most DTS parsers don't handle the core of DTS-HD tracks well. They show wrong runtime information. eac3to should show the correct runtime for Blu-Ray/HD DVD DTS-HD extracted core tracks. |
|
25th August 2008, 02:44 | #5918 | Link |
Registered User
Join Date: Feb 2008
Posts: 14
|
Madshi
I'm going through a manual process, extract each file and then recombine, so far so good. To answer your question, yes that last m2ts is tiny. I'll be happy to retry this process when you have a new eac3to available. One thing I can't do with my manual process is recombine the sup files into one so I'll hopefully get that done when you try your new version. Awesome tool and if any further details would be useful, I'd be happy to provide them. Thanks [QUOTE=madshi;1174297]Please retry with the next eac3to build. Or if you're in a hurry, you can eventually work around the problem by deleting (or renaming) the last m2ts part that is listed by eac3to for the movie. That last part is probably very small, right? |
25th August 2008, 11:15 | #5919 | Link | |
Registered User
Join Date: Jul 2008
Posts: 93
|
@Madshi
If source is having discontinuity, what does Eac3to does? Does it delete it or put empty block thr? Quote:
|
|
26th August 2008, 00:43 | #5920 | Link | |
Registered User
Join Date: Jul 2007
Posts: 48
|
Quote:
Here is the specific workflow, and what I experienced. I extracted an AVC elementary stream (with tsremux, and tsmuxer; tried both). I extracted a core DTS elementary stream with eac3to. I muxed those with mkvmerge. The audio/video was badly out of sync. I used eac3to to make an AC3 of the DTS-HD 7.1 track. I muxed again with mkvmerge. The audio/video were perfectly in sync. (A check of times of the audio tracks revealed the DTS core track to be a couple seconds shorter than the AC3 track, and that the AC3 track matched to the millisecond the duration of the video track.) Now... as some additional info... if you extract a -core DTS file with eac3to, versus if you convert to .wavs and then make a DTS file from those .wavs with eac3to (using Surcode), you will get files of slightly different time lengths. ("How do you get time lengths?"... mux to mkv or mka and use AVIMux gui...) And, in my limited experience, the time of the eac3to/SurCode-generated DTS file will always match the time of the video track (whether that be AVC or VC-1... can't remember a MPEG-2/DTS combo), whereas the eac3to/core DTS file will not. That seems problematic to me. I use spdifer as my DTS "decoder." |
|
Tags |
eac3to |
Thread Tools | Search this Thread |
Display Modes | |
|
|