eac3to - audio conversion tool

[rebkell]

timestamp derived FPS is used for gap checking instead of video bitstream FPS

Could you explain that one a little bit? I have captures that lose audio and it skips PTS and DTS timestamps, before correcting itself and the gap correction in eac3to didn't handle it correctly(which was totally understandable), just wondering how this change will work with those files.

[madshi]

Originally Posted by d1g1ta7

On the NBC HDTV muxes used to distribute programming to network affiliates in the US, NBC sends the surround audio via 3 stereo tracks - the first contains front left and front right audio, the second contains the center and lfe, the third contains rear left and rear right. Would it be possible to combine these tracks in eac3to, outputting as 5.1?

Your wish to combine those 3 tracks to one would be hard to express via command line. So I think the best solution would be to demux all 3 tracks to "WAVs", that should give you 6 mono WAV files. Then you can combine those back together to one multichannel file. Currently eac3to can not combine multiple mono WAV files into one multichannel WAV, but there are other tools that can do that (e.g. wavewizard).

Originally Posted by Snowknight26

Only the last track is Finnish.

And then funny enough, the next mkv I had muxed says

Only the last track has that description.

Samples can be provided if needed.

Yes, please. Samples would be appreciated.

Originally Posted by Snowknight26

And that Æ is really a ´. Guess eac3to doesn't support unicode?

The command line itself doesn't support unicode, IIRC. eac3to does for file names, but not for some other things...

Originally Posted by rebkell

timestamp derived FPS is used for gap checking instead of video bitstream FPS

Could you explain that one a little bit? I have captures that lose audio and it skips PTS and DTS timestamps, before correcting itself and the gap correction in eac3to didn't handle it correctly(which was totally understandable), just wondering how this change will work with those files.

If there is a file which has different timestamps than the video bitstream framerate information suggests, older eac3to versions reported gaps/overlaps which weren't there. This shouldn't happen after this change, anymore. But I've no idea if that helps with the specific captures you have.

[Snowknight26]

Originally Posted by madshi

Yes, please. Samples would be appreciated.

http://www.stfcc.org/misc/eac3to/11-14.mkv
http://www.stfcc.org/misc/eac3to/1408.mkv
http://www.stfcc.org/misc/eac3to/thirdman.mkv

Originally Posted by madshi

The command line itself doesn't support unicode, IIRC. eac3to does for file names, but not for some other things...

It does when you do cmd /u.

Another issue(?):

G:\Encoding Tools\eac3to>eac3to.exe 24.s01e01.mkv
MKV, 1 video track, 1 audio track, 0:42:44, 24p /1.001
1: h264/AVC, English, 692x472 23.976p
2: AC3 Surround, English, 2.0 channels, 192kbps, 48khz, dialnorm: -27dB
v01 The video track has a non-standard framerate.

http://www.stfcc.org/misc/24.s01e01.mkv

[Jeff Flowerday]

Madshi:

Thanks for the mkv support, very much appreciated!

I have a wish list item:

With more and more concerts footage coming out on Blu-Ray, it would be real sweet if you could add a split by chapter option when converting the lossless audio to flac files. Of course it would only work when reading an actual Blu-Ray structure.

[madshi]

Originally Posted by Snowknight26

http://www.stfcc.org/misc/eac3to/11-14.mkv
http://www.stfcc.org/misc/eac3to/1408.mkv
http://www.stfcc.org/misc/eac3to/thirdman.mkv

Thanks. "23.975" was due to truncating instead of rounding. It was "23.9758...". The next build will round that to 23.976. All tracks having the same "description" will also be fixed in the next build. A bigger problem is that eac3to doesn't like the h264/AVC tracks in your MKVs. This is caused by the video stream itself not containing any sequence headers. Because of that eac3to just lists the MKV properties of the video track instead of parsing the video bitstream itself. You can see that by the tracks being listed as "V_MPEG4/ISO/AVC". All video and audio tracks beginning with "V_" or "A_" are Matroska names. If tracks are listed like that, eac3to was not able to fully understand/parse the video/audio bitstream. Will have to work on that for next week. That's probably the problem with MKV: There are so many "funny" files out there which are different from what eac3to itself creates. So it might take a while until all files are properly supported.

BTW, if anybody is interested, you can use the undocumented switch "-logmkv" to get a tree structure of the MKV file. It's quite similar to what "mkvinfo" outputs. That way you can see whether eac3to read your MKV file correctly...

Originally Posted by Snowknight26

Another issue(?)

The video in that MKV is encoded with 23.976/1.000fps. I consider that "non-standard". The correct framerate would be 24.000/1.001fps. That's why eac3to (correctly) posts a warning. You can fix the problem by using "eac3to 24.s01e01.mkv fixed.mkv -slowdown". That will patch the video bitstream from 23.976/1.000 to 24.000/1.001. I don't think you will notice a difference when watching, though. Would be just for "peace of mind".

Originally Posted by Jeff Flowerday

I have a wish list item:

With more and more concerts footage coming out on Blu-Ray, it would be real sweet if you could add a split by chapter option when converting the lossless audio to flac files. Of course it would only work when reading an actual Blu-Ray structure.

Don't know, that's more difficult than it might seem. The eac3to infrastructure wasn't really built to split output files. Just imagine that eac3to finds out that the FLAC files need a second pass: eac3to would have to enumerate through all chapters again, reopen every of those separate FLAC files and redo them! That's a logistical nightmare...

Can't foobar2000 split FLAC files into chapters somehow? I thought I had seen something like that...

[Snowknight26]

Originally Posted by madshi

A bigger problem is that eac3to doesn't like the h264/AVC tracks in your MKVs. This is caused by the video stream itself not containing any sequence headers. Because of that eac3to just lists the MKV properties of the video track instead of parsing the video bitstream itself. You can see that by the tracks being listed as "V_MPEG4/ISO/AVC". All video and audio tracks beginning with "V_" or "A_" are Matroska names. If tracks are listed like that, eac3to was not able to fully understand/parse the video/audio bitstream.

Strange. The only thing that they share in common is that they were all muxed with mkvmerge.

Originally Posted by madshi

The video in that MKV is encoded with 23.976/1.000fps. I consider that "non-standard". The correct framerate would be 24.000/1.001fps. That's why eac3to (correctly) posts a warning. You can fix the problem by using "eac3to 24.s01e01.mkv fixed.mkv -slowdown". That will patch the video bitstream from 23.976/1.000 to 24.000/1.001.

Is that all it does? It won't keep the audio muxed into the mkv?

[Thunderbolt8]

thanks again for new, mkv demuxing & getting back the full video data is really useful!

[yesgrey]

Originally Posted by madshi

eac3to v3.06 released

* added demux support for MKV "modern style" MPEG2, VC-1 and h264/AVC tracks

Thank you very much! It's great having mkv support!

I suppose eac3to adds the Aud's when demuxing h264 streams, right?

[nautilus7]

Thanks for the update. New features are always welcome.

[mikelebron]

I have a quad core.. is eac3to optimized for a quad core? Are there any settings that I could benefit from? Also want to say great program.. I appreciate your efforts!

[shambles]

awesome update, thankyouverymuch!

[mini-moose]

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.

thanks

[rcjc]

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?

[Blue_MiSfit]

Madshi,

Thanks so much for looking into the clipping problem! It makes sense that it's a libavcodec problem. I look forward to an update

I can't adequately express how awesome this program is, and how even more awesome the quality of support and frequency up updates are!!

Thank you!!

-MiSfit

[yonta]

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.
http://www.sendspace.com/file/nq923t



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.
http://www.sendspace.com/file/p6c0ta

[madshi]

Originally Posted by Snowknight26

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.

Originally Posted by Snowknight26

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.

Originally Posted by yesgrey3

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).

Originally Posted by mikelebron

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...

Originally Posted by mini-moose

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.

Originally Posted by rcjc

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...

Originally Posted by yonta

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.

Originally Posted by yonta

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.

[GZZ]

I think I found a small cosmetic error when parsing a playlist file:

Not sure it should say 5+5+5+5+5+5...... it should just be [4+5].m2ts

Originally Posted by madshi

Some playlists are really that stupid. I don't think it's a bug.

I notice that sometimes when trying to parse the associated stream files for the playlist can take longer time then a normal playlist that dosnt contain 5+5+5+5+5+5.... Is it because your program try to read all the files (the same file over and over again) until it has read it the number of times its shown. In this example it will be like 20 times. I think removing the console showing duplicated files from the list will be more readable for the user.

/GZZ

[ultratoto14]

Thanks madshi for the support of mkv as input.

[Guest]

Originally Posted by madshi

A bigger problem is that eac3to doesn't like the h264/AVC tracks in your MKVs. This is caused by the video stream itself not containing any sequence headers.

The SPS's and PPS's are stored in the CodecPrivate data. It's easy to extract them. When demuxing, you should extract them and inject them at the start of the demuxed stream.

Because of that eac3to just lists the MKV properties of the video track instead of parsing the video bitstream itself. You can see that by the tracks being listed as "V_MPEG4/ISO/AVC". All video and audio tracks beginning with "V_" or "A_" are Matroska names. If tracks are listed like that, eac3to was not able to fully understand/parse the video/audio bitstream.

See above.

All the MKV files with AVC I've seen have "V_MPEG4/ISO/AVC" as the CodecID. Are you saying some files don't use that? What do they use?

[madshi]

Originally Posted by neuron2

The SPS's and PPS's are stored in the CodecPrivate data. It's easy to extract them. When demuxing, you should extract them and inject them at the start of the demuxed stream.

Yes, thanks. I'm planning to do that for the next release. But I'm thinking: Maybe it would be better to inject them not only at the start of the stream, but also in front of every I(DR) frame? Because I think in the original h264 stream normally sequence headers are stored in front of every I frame.

Originally Posted by neuron2

All the MKV files with AVC I've seen have "V_MPEG4/ISO/AVC" as the CodecID. Are you saying some files don't use that?

No no, you're right that MKV files usually use "V_MPEG4/ISO/AVC". I haven't seen any other codec ID than that. What I meant was that eac3to normally displays "h264/AVC", if it can properly parse such a video bitstream. The fact that eac3to displayed "V_MPEG4/ISO/AVC" means that it was not able to properly parse the bitstream. That's all I meant.

However, I do think that in theory it would be possible to have h264 MKV files which are not using "V_MPEG4/ISO/AVC", but "V_MS/VFW/FOURCC" instead, just as some VC-1 MKVs do, but with "avc1" in the CodecPrivate's BitmapInfoHeader. So eac3to also accepts "V_MS/VFW/FOURCC" with "avc1" as valid h264/AVC MKVs, too, just to be safe...