View Single Post
Old 1st February 2009, 20:39   #8098  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
eac3to v3.06 released

http://madshi.net/eac3to.zip

Code:
* added MKV reading/parsing support
* added demux support for MKV (E-)AC3, DTS(-HD), AAC, MPx, FLAC and WAV tracks
* added demux support for MKV "modern style" MPEG2, VC-1 and h264/AVC tracks
* reading from (HD) DVD and Blu-Ray drives uses different reading APIs now
* empty tracks in TS/m2ts container are not listed, anymore
* for 24.000 fps video tracks a little warning is displayed now
* when demuxing subtitle files, the number of captions is added to the filename
* timestamp derived FPS is used for gap checking instead of video bitstream FPS
* fixed: 44.1khz AC3 encoding was still broken
* fixed: zero byte stripping pass was done for true 24bit TrueHD tracks
* fixed: downconverting WAV files with 0x3f channel mask didn't work
* fixed: log output "remaining delay [...]" was sometimes wrong for AC3 tracks
* fixed: silent frame creation was tried for E-AC3 although it can't work
Please note that MKV read support is not complete yet. E.g. subtitles and chapters can't be demuxed yet. Also some MKV files muxed with old versions of mkvtoolnix, gdsmux or other muxing tools may not work correctly. If you run into any trouble with audio/video tracks, just let me know.

Good news is that MKV video muxing and demuxing is now a transparent operation, if you use eac3to both for muxing + demuxing. In other words: If you mux a video track with eac3to and then demux it again, you'll get the exact same data back. No changes, nothing missing... *)

-------

*) exceptions:

(1) of course eac3to does some video bitstream manipulations like cropping 1088 to 1080, removing padding bytes etc, but these changes are done intentionally and are not caused by muxing/demuxing
(2) VC-1 muxing loses the very last video frame, don't know why
madshi is offline