View Single Post
Old 2nd February 2009, 08:32   #8116  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by Snowknight26 View Post
Strange. The only thing that they share in common is that they were all muxed with mkvmerge.
Which mkvmerge version? Older versions removed the sequence headers from the stream. Don't know if the latest version still does that.

Quote:
Originally Posted by Snowknight26 View Post
Is that all it does? It won't keep the audio muxed into the mkv?
It will modify the video bitstream and mux it into a new MKV file. The audio track will be demuxed, you'll have to add it back into the new MKV file with mkvmerge.

Quote:
Originally Posted by yesgrey3 View Post
I suppose eac3to adds the Aud's when demuxing h264 streams, right?
Yes. And I double checked to make sure that the AUDs which are added back in are 100% identical to what they were in the original file. The AUDs are not stored in the MKV file. But the h264 specification says clearly enough how AUDs have to look like, so I was able to reproduce them perfectly (at least with the h264 file I was testing with).

Quote:
Originally Posted by mikelebron View Post
I have a quad core.. is eac3to optimized for a quad core? Are there any settings that I could benefit from?
eac3to uses multiple threads wherever it seems appropriate. If you do simple things using quad core doesn't help over using single core. But with CPU intensive tasks like e.g. resampling audio or decoding multiple audio tracks at the same time, eac3to uses multiple threads. So it should make use of your quad core quite well. Often the speed of your harddisk is the limiting factor, though...

Quote:
Originally Posted by mini-moose View Post
having an issue I think I read many have but I couldn't find any suggested solution other than installing nero (I dislike any nero after v6) :

eac3to v3.06
command line: eac3to.exe F:\00005.m2ts 2: C:\0005.ac3 -640
------------------------------------------------------------------------------
TrueHD/AC3, 5.1 channels, 48khz, dialnorm: -27dB
(embedded: AC3, 5.1 channels, 448kbps, 48khz, dialnorm: -27dB)
Extracting TrueHD stream...
Removing TrueHD dialog normalization...
Decoding with libav/ffmpeg...
Encoding AC3 <640kbps> with libAften...
Creating file "C:\0005.ac3"...
[libav] Lossless check failed - expected 2c, calculated 43 <WARNING>
[libav] Lossless check failed - expected 90, calculated a4 <WARNING>
[libav] End of stream indicated <WARNING>
The original audio track has a constant bit depth of 16 bits.
eac3to processing took 3 minutes, 51 seconds.
Done.
It's not a problem, if it only occurs once or twice. Especially if it's directly before "end of stream". Every such warning means that maybe 0.8ms of your audio file might not be perfectly lossless. The other millions of milliseconds in the audio file are still lossless.

Quote:
Originally Posted by rcjc View Post
Like with mini-moose's TrueHD track with an embedded 448kbps 5.1 AC3 track, is there any benefit in encoding that TrueHD track to 640kbps AC3 or 1536or768 DTS versus just extracting and using the embedded 448 AC3?
I wouldn't use DTS 768kbps. Using 640kbps AC3 or 1536kbps DTS *may* produce slightly better results than the 448kbps AC3 core track. But I don't really know. It also depends on how good the encoders are you're using...

Quote:
Originally Posted by yonta View Post
MKV, 1 video track, 1 audio track, 1 subtitle track, 0:00:11, 60i /1.001
"SPORTSILLUSTRAT", TNT in HD (TNTH)
1: MPEG2, English, 1080i60 /1.001 (16:9)
"MPEG2 1080i"
2: AC3, English, 5.1 channels, 448kbps, 48khz, dialnorm: -27dB
"DD5.1 448k"
3: Subtitle (SRT)

eac3to says there's a SRT subtitle in this file when there's no subtitle.
Actually there are closed captions contained in that MPEG2 video track, which eac3to can (theoretically) extract to a SRT file. So the track listing is correct. However, actually trying to extract the SRT doesn't seem to work in this particular case, so I'll have to look into that.

Quote:
Originally Posted by yonta View Post
MKV, 1 video track, 1:30:18, 23.999p
1: h264/AVC, 1080p24 (16:9)
[v01] The video bitstream framerate field doesn't match the container framerate. <WARNING>
[v01] The video framerate is correct, but rather unusual. <WARNING>

This is the log on an exact 24.000fps file.
Will be fixed in the next build.
madshi is offline