eac3to - audio conversion tool

Not yet. madshi once said that he'll consider it for his todo list.

[yesgrey]

Do you know if is there any other tool that could do it? cut the last part of a n h264 video file?

[TinTime]

Originally Posted by yesgrey3

Do you know if is there any other tool that could do it? cut the last part of a n h264 video file?

What are you backing up to? If it's in an mkv container you can split it with mkvmerge.

[yesgrey]

Originally Posted by TinTime

What are you backing up to? If it's in an mkv container you can split it with mkvmerge.

That's good enough for what I need. Since I have to use mkvmerge to join the video/audio/subs/chapters, it would be the best solution... I should have looked more carefully in mkvmerge before asking for it...

Thank you very much!

[Cela]

eac3to does not like most of my "Xvid.avi" recordings produced with Total Recorder.
As a consequence, multiAVCHD and tsMuxeR produce issues.

A short example for debugging is here (9606 KB).
A longer example (application of eac3to within multiAVCHD, uncrop) is here (19331 KB).

Now, the multiAVCHD workflow must be interrupted since eac3to refuses to demux these files. Demuxing must be performed with VirtualDub. VirtualDub's wav must be seperately imported into multiAVCHD.
RipBot's ffmpeg demuxing finishes, but may also produce issues (sometimes adds weird clicks as 'watermarks').

VirtualDub has no problem to edit, append and demux these avi files, though.

It would be a great advantage for the workflow, if eac3to did not refuse the demuxing of these "Xvid.avi" recordings.

Please upgrade eac3to/eac3to_more_gui accordingly.

Thanks.

[tebasuna51]

@Cela
You don't need samples to prove this, eac3to (or TsMuxer) don't support avi container.

[Cela]

Yes, I was afraid to get this response.

But, why?
I would like it did. I would need it.

I wanted to do my share to get things moving.

Edit:
Dean, the author of multiAVCHD, adviced me to update to newest eac3to and to correct an input typo.
Now multAVCHD's workflow, using newest eac3to.exe, works like a charm!

And, within multiAVCHD, tsMuxeR does not need to deal with the original avi any more.

[LeXXuz]

Originally Posted by LeXXuz

When I use eac3to to demux evo-Containers with the -demux switch, eac3to demuxes not all the streams (especially subtitles with ID: 28 and up).

Is there a way to fix this or can I demux multiple streams at once WITHOUT converting them?

Any ideas?

[Moondust]

I've encountered a very strange problem with EAC3TO, at least to me. I loaded my copy of Ice Age 2 in eac3to. It said the length of the movie was 1h 30m 38s (all playlists). I ripped the Dutch 768kbps audiotrack. But when I played that seperate track in MPC-HC it was 1h 32m 15s. Other players and MediaInfo revealed the same. EAC3TO says the seperate audiotrack is 1h 30m 38s. I am confused. Who is right? And why?

EAC3TO source info.

D:\EAC3TO>eac3to e:\downloads\newsleecher 1)
M2TS, 1 video track, 5 audio tracks, 5 subtitle tracks, 1:30:38, 24p /1.001
1: Chapters, 24 chapters
2: MPEG2, 1080p24 /1.001 (16:9)
3: DTS Master Audio, English, 5.1 channels, 24 bits, 48khz
(core: DTS, 5.1 channels, 24 bits, 1509kbps, 48khz)
4: DTS, Dutch, 5.1 channels, 24 bits, 768kbps, 48khz
5: DTS, Dutch, 5.1 channels, 24 bits, 768kbps, 48khz
6: AC3, English, 2.0 channels, 224kbps, 48khz, dialnorm: -27dB
7: AC3, English, 2.0 channels, 224kbps, 48khz, dialnorm: -27dB
8: Subtitle (PGS), English
9: Subtitle (PGS), Dutch
10: Subtitle (PGS), Dutch
11: Subtitle (PGS), Dutch
12: Subtitle (PGS), English

EAC3TO seperate audio track info.

D:\EAC3TO>eac3to e:\IceAge2Dutch.dts
DTS, 5.1 channels, 1:30:38, 24 bits, 768kbps, 48khz

[TinTime]

Originally Posted by LeXXuz

When I use eac3to to demux evo-Containers with the -demux switch, eac3to demuxes not all the streams (especially subtitles with ID: 28 and up).

Is there a way to fix this or can I demux multiple streams at once WITHOUT converting them?

You can demux streams by specifying the target as the same type as the source. For example, if track 3 is ac3, 4 is dts...

eac3to.exe source 3: output3.ac3 4: output4.dts

...will demux those tracks.

[AnryV]

Originally Posted by tebasuna51

I can't reproduce your problem extracting dts core:

eac3to v3.16
command line: "D:\eac3to.exe" "D:\Queen.dtshd" "D:\Queen_core.dts"
------------------------------------------------------------------------------
DTS Hi-Res, 5.1 channels, 0:00:14, 24 bits, 3018kbps, 96khz
(core: DTS, 5.1 channels, 0:00:14, 24 bits, 1509kbps, 48khz)
Creating file "D:\Queen_core.dts"...
eac3to processing took 1 second.
Done.

Please

I have 16 bits DTS Hi-Res.

[Snowknight26]

It doesn't matter what it says as DTS-HD HR doesn't have a bit depth. No lossy formats do.

[rik1138]

Originally Posted by Snowknight26

It doesn't matter what it says as DTS-HD HR doesn't have a bit depth. No lossy formats do.

Sure they do... DTS HD retains the bit depth of the source files used to create it (or, at the very least, it's recording the bit-depth in the header information...). I can encode a 24-bit DTS-HD HR file and a 16-bit DTS-HD HR file (using 24-bit or 16-bit source WAVs). eac3to decodes them differently (but reports the bit depth correctly). I tried it with a stereo file and a 5.1 file, the 5.1 one was the only one that eac3to said it was 'Patching bitdepth to 24 bits...'

Obviously, it didn't say this on the 24 bit 5.1 file, and it didn't do it on the 16 bit 2.0 file (not sure why).

Here's a 16-bit 5.1 DTS-HD HR file if you want to try it:

http://www.sendspace.com/file/usnwqd

Rik

[tebasuna51]

Originally Posted by rik1138

Sure they do... DTS HD retains the bit depth of the source files used to create it (or, at the very least, it's recording the bit-depth in the header information...)

Only the last part is true: "recording the bit-depth in the header"
Like Snowknight26 say you, only losless encoders (like DTS-MA) can preserve the bitdepth.

I say to madshi don't put this header info in Eac3to logs because can induce to mistakes.
But I agree with madshi when change the header mark with 24 no matter the original source was. Always is better decode to 24 bits instead 16. Don't worry.

[tebasuna51]

Originally Posted by Moondust

I loaded my copy of Ice Age 2 in eac3to. It said the length of the movie was 1h 30m 38s (all playlists). I ripped the Dutch 768kbps audiotrack.

But when I played that seperate track in MPC-HC it was 1h 32m 15s.

EAC3TO says the seperate audiotrack is 1h 30m 38s. I am confused. Who is right? And why?

Use DelayCut to fix the DTS (remove internal pad's) and you can obtain the same value with all methods.

[shambles]

Originally Posted by drlove

Hi, after using eac3to w/o -keepdiagnorm my TrueHD track has no diagnorm info at all and my A/V interpret that as -0dB and normalize to -31dB = the volume is very low. If I run the eac3to ones again on the track the log shows no diagnorm value at all, shouldn't eac3to sett the diagnorm to -31dB and not remove the value?

eac3to has used -31db instead of 0db for a while now for that exact reason.. unless something is broken in the latest build, just running the file through eac3to again should set the flag to -31db eventhough eac3to doesn't show it (with -31db and 0db, no dialnorm value is shown)

[AnryV]

Originally Posted by Snowknight26

It doesn't matter what it says as DTS-HD HR doesn't have a bit depth. No lossy formats do.

I asked not about it, but how to forbid eac3to to change the original information.

[Thunderbolt8]

it doesn't change the original information, because as shadowknight said, lossy tracks have no bit depth. therefore it doesn't matter if theres written 16 or 24 bit.

[AnryV]

Originally Posted by Thunderbolt8

it doesn't change the original information, because as shadowknight said, lossy tracks have no bit depth. therefore it doesn't matter if theres written 16 or 24 bit.

It change the information about 16 or 24 bit of the source.

[Snowknight26]

Which is completely irrelevant and sometimes not even correct.