eac3to - audio conversion tool

[Batman007]

Try:
eac3to.exe "D:\MeGUI 2418\MeGUI output\AVSEQ02 Tc0 L2 2ch 48 224 DELAY 0ms.mp3" "101 D.
mp3" -slowdown
I've audio having frame rate 29.970 FPS
Which code should be used ? I'm new to eac3to .. I don't know much. . Please tell me the whole code ...

[LigH]

From 29.970 to 23.976 fps, do not change the audio. Inverse Telecine (IVTC) does not change the playtime.

[Batman007]

From 29.970 to 23.976 fps, do not change the audio. Inverse Telecine (IVTC) does not change the playtime.
But I've encoded from 25 to 23.976 and it had changed duration... That was done with MeGUI
But MeGUI doesn't support 29.970 audio !
That's why I'm looking for eac3to

[LigH]

Of course. Converting a video from PAL (25.0 fps) to NTSC-Film (23.976 fps) does change the playing time if you use the slowdown method.

But converting a video from NTSC (29.97 fps) to NTSC-Film (23.976 fps) does not change the playing time if the video was telecined and can be reverted to progressive using IVTC. Therefore, MeGUI does not need to offer any audio conversion. The audio does not need any conversion, because the playing time won't change. But only if you can invert a telecine.

[Batman007]

Of course. Converting a video from PAL (25.0 fps) to NTSC-Film (23.976 fps) does change the playing time if you use the slowdown method.

But converting a video from NTSC (29.97 fps) to NTSC-Film (23.976 fps) does not change the playing time if the video was telecined and can be reverted to progressive using IVTC. Therefore, MeGUI does not need to offer any audio conversion. The audio does not need any conversion, because the playing time won't change. But only if you can invert a telecine.
What if I convert 29.970 to 25.000 fps...
And then convert it to 23.976 ?

[LigH]

What if you first read basic material about video before confusing this thread?

[szabi]

Hi

Are there any development handling dolbyTrueHD audio?
It can extract the THD stream, but not the AC3 core, neither THD+AC3.
Any way to extract AC3 core?
Suggestions are welcomed.

bye
szabi

[Snowknight26]

I have a Blu-ray that causes eac3to to show only one playlist (the wrong playlist), even though playing index.bdmv plays a different one (the correct one). I've zipped (http://stfcc.org/misc/eac3to playlist sample.zip) the contents of the PLAYLIST folder and included a few files for debugging.. if madshi still secretly develops this. ;)

[Music Fan]

Are there any development handling dolbyTrueHD audio?
It can extract the THD stream, but not the AC3 core, neither THD+AC3.
Any way to extract AC3 core?
Suggestions are welcomed.
With TSmuxer, check "downconvert True HD ..." in track options and choose demux as output format. Don't worry, that's an extraction, not a conversion (encoding).

[madshi]

I have a Blu-ray that causes eac3to to show only one playlist (the wrong playlist), even though playing index.bdmv plays a different one (the correct one). I've zipped (http://stfcc.org/misc/eac3to playlist sample.zip) the contents of the PLAYLIST folder and included a few files for debugging.. if madshi still secretly develops this. ;)
Ooops, too late. Why didn't you create a bug tracker entry for this, then I might have looked at it. Now 3.28 is already done.

Anyway, are you sure that the real playlist and the one selected by eac3to are really different? Often there are multiple duplicates, and eac3to simply selects one "by random".

[madshi]

eac3to v3.28 released

http://madshi.net/eac3to.zip

* fixed: #001: different number of frames for left and right eye
* fixed: #061: valid silence edit was sometimes rejected
* fixed: #067: error messages were not available to GUIs
* fixed: #086: left/right eye information was inverted in some 3D Blu-Rays
* fixed: #131: TrueHD Atmos streams could not be demuxed or decoded
* fixed: #243: ArcSoft DTS decoder crash made eac3to crash, too
* downStereo: added 0.7071 factor for surround/back channels (ITU-R BS.775-3)
* downStereo/Dpl: using 0.5 instead of 0.7071 factor for LFE (ITU-R BS.775-3)
Please note that some of these changes have been implemented without a lot of testing. So it would be great if you guys could double check things, especially the changes, to make sure they really work as intended. Also please make sure TrueHD decoding still works losslessly, as usual (even for non-Atmos tracks). I've hacked Atmos "support" into the old ffmpeg version I've been using for years, so I wouldn't have to update to the latest ffmpeg version. Don't have much time atm, so I tried to do the most important stuff with the least amount of work.

[Stereodude]

With TSmuxer, check "downconvert True HD ..." in track options and choose demux as output format. Don't worry, that's an extraction, not a conversion (encoding).
TrueHD has no core in the sense that DTS-HD does. You can't extract what isn't there. If it's not THD+AC3 there's nothing to extract. It would have to be encoded.

[jpsdr]

I've hacked Atmos "support" into the old ffmpeg version I've been using for years, so I wouldn't have to update to the latest ffmpeg version.

Is there a reason to stay with a several years old ffmpeg version ? There's probably been a lot of fixes and improvements since.

[Boulder]

TrueHD has no core in the sense that DTS-HD does. You can't extract what isn't there. If it's not THD+AC3 there's nothing to extract. It would have to be encoded.There is something to extract, for example the latest version of mkvmerge can get the embedded AC3 track for you.

[madshi]

Is there a reason to stay with a several years old ffmpeg version ? There's probably been a lot of fixes and improvements since.
Have you bothered to read the announcement post? Read the last sentence again.

[r0lZ]

The bug #86 with the inversion of the left and right eye views when displaying the content of a 3D playlist with the MVC_Base_view_R_flag true is partially fixed.

When eac3to is launched with the BD path as the argument, or with the playlist, it works fine:

C:\>eac3to.exe Y:\BDMV\PLAYLIST\00852.mpls
1) 00852.mpls, 00001.m2ts, 1:34:02
- Chapters, 20 chapters
- h264/AVC (right eye), 1080p24 /1.001 (16:9)
- h264/MVC (left eye), 1080p24 /1.001 (16:9)
- DTS Master Audio, English, multi-channel, 48kHz
- DTS, French, multi-channel, 48kHz
- AC3, Spanish, multi-channel, 48kHz
- AC3, Portuguese, multi-channel, 48kHz
- AC3, Danish, multi-channel, 48kHz
- AC3, Finnish, multi-channel, 48kHz
- AC3, Norwegian, multi-channel, 48kHz
- DTS, Russian, multi-channel, 48kHz
- AC3, Swedish, multi-channel, 48kHz
- AC3, Chinese, multi-channel, 48kHz
- DTS, Japanese, multi-channel, 48kHz

But when the 1) argument is added to display the full content of the playlist, the left and right views are still inverted:

C:\>eac3to.exe Y:\BDMV\PLAYLIST\00852.mpls 1)
M2TS, 2 video tracks, 11 audio tracks, 12 subtitle tracks, 1:34:02, 24p /1.001
1: Chapters, 20 chapters
2: h264/AVC (left eye), 1080p24 /1.001 (16:9)
3: h264/MVC (right eye), 1080p24 /1.001 (16:9)
4: DTS Master Audio, English, 7.1 (strange setup) channels, 16 bits, 48kHz, -9ms
(core: DTS-ES, 5.1 channels, 1509kbps, 48kHz)
5: DTS, French, 5.1 channels, 768kbps, 48kHz, -9ms
6: AC3, Spanish, 5.1 channels, 448kbps, 48kHz, dialnorm: -27dB, -9ms
7: AC3, Portuguese, 5.1 channels, 448kbps, 48kHz, dialnorm: -27dB, -9ms
8: AC3, Danish, 5.1 channels, 448kbps, 48kHz, dialnorm: -27dB, -9ms
9: AC3, Finnish, 5.1 channels, 448kbps, 48kHz, dialnorm: -27dB, -9ms
10: AC3, Norwegian, 5.1 channels, 448kbps, 48kHz, dialnorm: -27dB, -9ms
11: DTS, Russian, 5.1 channels, 768kbps, 48kHz, -9ms
12: AC3, Swedish, 5.1 channels, 448kbps, 48kHz, dialnorm: -27dB, -9ms
13: AC3, Chinese, 5.1 channels, 448kbps, 48kHz, dialnorm: -27dB, -9ms
14: DTS, Japanese, 5.1 channels, 768kbps, 48kHz, -9ms
15: Subtitle (PGS), English
16: Subtitle (PGS), French
17: Subtitle (PGS), Spanish
18: Subtitle (PGS), Portuguese
19: Subtitle (PGS), Danish
20: Subtitle (PGS), Finnish
21: Subtitle (PGS), Norwegian
22: Subtitle (PGS), Russian
23: Subtitle (PGS), Swedish
24: Subtitle (PGS), Chinese
25: Subtitle (PGS), Japanese
26: Subtitle (PGS), Japanese

(This is the Ice Age 3 3D Panasonic Bundle. I haven't tested with the 2 other 3DBDs I have with the inverted views, but I guess they give the same result.)

[madshi]

I'll need a sample. One which is complete enough so I can fully reproduce the incorrect listing.

[tebasuna51]

eac3to v3.28 released
Thanks madshi!

Also please make sure TrueHD decoding still works losslessly, as usual (even for non-Atmos tracks).
I'll make some test and report.

* downStereo: added 0.7071 factor for surround/back channels (ITU-R BS.775-3)
No problem for me, that enhance a little the front channels info (more important) over the surround channels.

* downStereo/Dpl: using 0.5 instead of 0.7071 factor for LFE (ITU-R BS.775-3)
I can't se this recomendation in ITU-R BS.775-3, I only read than LFE don't be used at all in downmix.

@all users
Please read ITU-R BS.775-3 (http://www.itu.int/rec/R-REC-BS.775-3-201208-I/ee) to understand for what add LFE is not recommended for downmix.
Use -mixlfe at your risk.

[Sparktank]

eac3to v3.28 released

Excellent update!


@all users
Please read ITU-R BS.775-3 (http://www.itu.int/rec/R-REC-BS.775-3-201208-I/ee) to understand for what add LFE is not recommended for downmix.
Use -mixlfe at your risk.

noted and PDF downloaded.

[madshi]

Thanks madshi!
Pleasure! It was about time... :o

I'll make some test and report.
Thanks, appreciated!

No problem for me, that enhance a little the front channels info (more important) over the surround channels.

I can't se this recomendation in ITU-R BS.775-3, I only read than LFE don't be used at all in downmix.
That's true. My thinking was like this:

Originally I mixed left, right and surround channels with 1.0, and the LFE with 0.7071. The reason for using 0.7071 for LFE was because it was originally only one channel/speaker, but I've mixed it into both the final left *and* right channels. So I had to half the volume of the LFE to not increase its final playback volume.

Now ITU 775-3 suggests to use 1.0 for left/right channel, but 0.7071 for the surround channels. The ITU idea is that the left/right channels should have higher priority than the surround channels. If we accept this idea, it should also be applied to the subwoofer. Why would we lower the surround channel volume for the mix, but not the LFE volume? Because of that I've used the original matrix, but added an 0.7071 factor on all channels (including LFE) except left/right. This is how I ended up with 0.7071 for the surround channels and 0.5 for the LFE.

ITU 775-3 does suggest not to mix the LFE at all, and IIRC that's eac3to's default behaviour, anyway. But *if* the user wants to mix the LFE, the volume should make sense, and since I just lowered the surround volume, I thought it would make sense to lower the LFE volume (when -mixlfe is used), accordingly.

[r0lZ]

I'll need a sample. One which is complete enough so I can fully reproduce the incorrect listing.
OK, I'll try to find a 3D short that can serve as an example. Currently, I can't do much better than the sample I gave you. I don't know how to cut the SSIF and the two M2TS files at the right position.

[madshi]

I don't think it has to be the "right" position. It just has to be big enough to allow eac3to to detect the video track properties. Probably something like 50MB for the first SSIF and 25MB for the first m2ts file would work ok. If the playlist contains multiple m2ts files, and the first one is smaller than 50MB, leave the first m2ts/ssif file untouched and shorten the 2nd one so that the overall sum is 25MB/50MB. Something like that. You can always test this right away on your PC: If eac3to reproduces the problem with your cut down sample, then you've done well and you can zip/upload it.

[r0lZ]

OK. But I don't understand why you need the video files. The flag is in the MPLS file only, and it should be sufficient to read it to know that the 2 views are inverted. Anyway, I am preparing a sample...

[Stereodude]

There is something to extract, for example the latest version of mkvmerge can get the embedded AC3 track for you.
Please explain to me how a tool can extract something that isn't there. THD has no core. THD is packed with an AC3 track on Blu-ray because the specs require it and some people call that the "core", but THD doesn't have a core. THD can be separated from the "core" (the ac3 packed with it) and still be decoded. For example, HD-DVD had THD with no AC3 track packed along side of it.

[madshi]

OK. But I don't understand why you need the video files. The flag is in the MPLS file only, and it should be sufficient to read it to know that the 2 views are inverted. Anyway, I am preparing a sample...
The reason is that there's a difference between implementing something with or without the ability to test it. I tried to implement it without being able to test it, and as you reported, my implementation only half worked. I don't know why it doesn't fully work, I thought it would. That's why I need the sample, so I can analyze better why it fails to work completely. If you're a dev you should know that it's important to be able to test something, instead of just implementing something "blindly". If you're not a dev, then that's ok, you probably couldn't know... :p

[r0lZ]

I'm a dev, and I know that if I get the right flag, it is easy to simply swap the left and right strings in the output. But I understand your point.

I did 3 samples, but none are perfect. When I cut 50MB of the SSIF and respectively 30 and 20 MB of the AVC and MVC M2TS files, eac3to can list the streams when using the "1)" argument (with the full parsing of the video file), but it lists only the chapters when used without the "1)" argument. I don't understand why, so I have made a new sample with file sizes twice as big. Same result!

My third test is completely different: I have taken a short menu file (one minute long) with the standard left/right order of the views, and I have patched the MPLS with an hex editor to set the base view R flag. IMO, my patch should be sufficient to invert the views, but I don't know if there are other differences regarding the left/right views order. Now, eac3to works exactly as described in my post above: correct without the "1)", but wrong with it. It lists all streams in both cases (without the subpics in the first case, but it's normal.) The total size of that sample is 621MB. A bit too much, but I should be able to post it somewhere. Unfortunately, I don't have any 3D clip with the views inverted short enough to be uploaded somewhere, so I had to use that trick.

Do you want the first sample, that doesn't show the video streams without the 1) argument, or the second one, fully working but big and not "official"?

[Boulder]

Please explain to me how a tool can extract something that isn't there. THD has no core. THD is packed with an AC3 track on Blu-ray because the specs require it and some people call that the "core", but THD doesn't have a core. THD can be separated from the "core" (the ac3 packed with it) and still be decoded. For example, HD-DVD had THD with no AC3 track packed along side of it.I don't know, you would have to ask Mosu about it.

2015-02-10 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: mkvmerge will now recognize TrueHD+AC3 files as consisting of two tracks. Instead of always dropping the AC3 part the user can simply select which tracks to keep. Part of the implementation of #1107.

[r0lZ]

When I cut 50MB of the SSIF and respectively 30 and 20 MB of the AVC and MVC M2TS files, eac3to can list the streams when using the "1)" argument (with the full parsing of the video file), but it lists only the chapters when used without the "1)" argument.
Sorry, I didn't know that it is necessary to include the CLIPINF directory as well. I have added it in the first sample, and now eac3to can lists the streams even without the 1) argument. I will upload that sample...

[EDIT] Sample uploaded. See the bug tracker for the link.

[szabi]

With TSmuxer, check "downconvert True HD ..." in track options and choose demux as output format. Don't worry, that's an extraction, not a conversion (encoding).

I tried, but did not worked.

[Q-the-STORM]

thanks madshi for the new version... I hope you have a bit more time in the future and replace aften with libav/ffmpeg for ac3 encoding :P

I don't know, you would have to ask Mosu about it.

alright..

on the BD there is a TrueHD track with an embedded AC3 track...
those 2 tracks can both work completely independently... you can "extract" the AC3 track and it will work without TrueHD and you can "extract" the TrueHD Track and it will work without the AC3 Track....

the AC3 Track is embedded for backward compatibility with receivers WITHOUT having to change to another audio track...
so people can bitstream it and if the receiver can't decode TrueHD, it can fall back on AC3....

BUT the big difference to DTS is, that DTS-HD will not work without the DTS core... that's why on DTS it's called a core and on TrueHD it's called embedded... on DTS-HD you can extract the core, but you can't have DTS-HD wihtout the core... DTS-HD is simply the Core + extra information to make it lossless (on DTS-HD MA at least)...

TrueHD is lossless all on it's own, it doesn't need the AC3 track at all.

so in eac3to you have the option to demux thd, ac3 or thd+ac3...
all of those options will give you one file...

and here's the thing:
the m2ts (Blu-ray) container supports embedded tracks, the matroska container doesn't!
so if you want to have a TrueHD track in mkv, you HAVE TO remove the embedded track!

in the past, mkvmerge did exactly this... They just removed the embedded AC3 track and muxed the TrueHD track only.
but there are people that want the AC3 track as well, they would have to extract the embedded AC3 track with eac3to or tsmuxer or any other tool seperately and then mux it.

Now mkvmerge eliminated this step. Instead of simply removing the embedded AC3 track, it gives the option to mux it in as a SEPERATE audio track. if you now bitstream the TrueHD track, your receiver does not have to option to fall back on AC3 anymore, you have to select the seperate ac3 track in your player...


now if you have a mkv file with a trueHD track, or you have extracted the TrueHD track with eac3to (and didn't use thd+ac3 extension) then there is no embedded AC3 Track anymore. If you want to get an AC3 track from it, it HAS to be encoded...

[Snowknight26]

Ooops, too late. Why didn't you create a bug tracker entry for this, then I might have looked at it. Now 3.28 is already done.

Anyway, are you sure that the real playlist and the one selected by eac3to are really different? Often there are multiple duplicates, and eac3to simply selects one "by random".

Aside from the different chapters they're identical.

Thanks for the new version regardless!

[madshi]

I'm a dev, and I know that if I get the right flag, it is easy to simply swap the left and right strings in the output.
Well, it's not as easy as it sounds, because when doing "1)" eac3to goes a totally different way. It analyzes the m2ts files and mostly disregards the mpls information. Only later the m2ts parsing results and the mpls information is tried to be tied together again. This is a quite complicated process (eac3to even tries to automatically find a matching playlist even if you manually entered a number of m2ts files instead of the mpls), and that's why it's not that easy to implement this without being able to test it.

Aside from the different chapters they're identical.
Oh. It's possible that eac3to isn't comparing the chapters when deleting "duplicate" playlists from the listing.

[Stereodude]

I tried, but did not worked.
That's because your TrueHD has no embedded AC3 track to extract. No tool can extract what isn't there. You can only extract AC3 from TrueHD+AC3 tracks.

[tebasuna51]

- Test decoding 5 standard TrueHD samples with different number of channels, bitdepth and samplerate:
the eac3to v3.27 and v3.28 output are bit-identical.

- Test decoding 3 TrueHD Atmos samples (I don't have many samples):
the eac3to v3.28 output and a recent ffmpeg are bit-identical.

- Test over 2 TrueHD Atmos samples extracting the AC3 core:
the eac3to v3.28 output is better than tsMuxeR extraction because tsMuxeR add extra garbage at end of the AC3.

[madshi]

Thanks for the tests!

[jpsdr]

Have you bothered to read the announcement post? Read the last sentence again.

You're absolutely right, i'm stupid i didn't see it, all my sincere appologies !

Thanks for your work.

[Overdrive80]

Hi, thanks for updated. For any reason, I never get update haali version according to eac3to (I install last version from http://haali.su/mkv/):

"Haali Matroska Muxer (2013-04-14) is installed
There's a new version (2013-06-23) available
http://haali.net/mkv"


Thanks
Any fix or workaround?

[Sparktank]

"Haali Matroska Muxer (2013-04-14) is installed
There's a new version (2013-06-23) available

IIRC, they're the same code.
The 4-14 was the beta version that was tested before releasing it as official (06-23).
The date is the only thing truly different as everything else remained identical in the official release.
For some reason the Haali site never really updated because I downloaded their binary and never got the 06-23 date to silence eac3to.

I use K-Lite Codec Pack, and they've since updated to the binary with the most recent date, just to please eac3to users.
Or OCD users.

I went weeks, maybe months before I even noticed KLCP updated the cosmetic date.

Somone might have a link to a binary with the date eac3to expects.
Or whatever codec pack you're using (if any), you could ask them to update their installer.

[mariner]

eac3to v3.28 released

http://madshi.net/eac3to.zip

* fixed: #001: different number of frames for left and right eye
* fixed: #061: valid silence edit was sometimes rejected
* fixed: #067: error messages were not available to GUIs
* fixed: #086: left/right eye information was inverted in some 3D Blu-Rays
* fixed: #131: TrueHD Atmos streams could not be demuxed or decoded
* fixed: #243: ArcSoft DTS decoder crash made eac3to crash, too
* downStereo: added 0.7071 factor for surround/back channels (ITU-R BS.775-3)
* downStereo/Dpl: using 0.5 instead of 0.7071 factor for LFE (ITU-R BS.775-3)
Please note that some of these changes have been implemented without a lot of testing. So it would be great if you guys could double check things, especially the changes, to make sure they really work as intended. Also please make sure TrueHD decoding still works losslessly, as usual (even for non-Atmos tracks). I've hacked Atmos "support" into the old ffmpeg version I've been using for years, so I wouldn't have to update to the latest ffmpeg version. Don't have much time atm, so I tried to do the most important stuff with the least amount of work.

Greetings madshi. Many thanks for the update.

[howzz]

in the process of trying to find ways to speedup the demuxing, muxing process, i came across one of the change logs that was mentioned here. i think it was version 2+ "improvement of the speed performance of the muxing process", or something that nature.

i am a long time user of Ripbot264. recently i moved my working folder from a secondary HDD to a primary SSD and noticed the initial demuxing process in ripbot went from 23 mins to 11 mins. i was looking for more ways to improve the speed of the demux and realized by moving to an even faster SSD made no difference. it got me thinking whether the DDR3 RAM speed is the factor, or is it the software ie. hali/eac3to etc..

According to Resource Monitor, the eac3to process (during ripbot264 demuxing), is only reading at 50~60MB/s and writing the video.mkv stream at about the same speed. And by moving to an even faster SSD, the SSD utilization does not go up, in fact, it's well under 100%. CPU utilization is less than 5% so it's not really fully utilizing the full potential of the SSD, or the CPU. the only other hardware i can think of would be the RAM. but before i go out and upgrade from DDR3 1866 to DDR3 2600, i just want to make sure that it's not the software.

could someone shed some light on this subject? is it Hali's fault? or is it a hardware limiting factor? my rig is i7 @4.8ghz with Crucial SSD M4 and Crucial MX100, DDR3 1866 16GB. what can i do to farther improve the demuxing speed.

thanks so much!

[tebasuna51]

... and noticed the initial demuxing process in ripbot went from 23 mins to 11 mins.

:logfile:
and we can say you how know the culprit.

[Nebudchanezzer]

in the process of trying to find ways to speedup the demuxing, muxing process, i came across one of the change logs that was mentioned here. i think it was version 2+ "improvement of the speed performance of the muxing process", or something that nature.

i am a long time user of Ripbot264. recently i moved my working folder from a secondary HDD to a primary SSD and noticed the initial demuxing process in ripbot went from 23 mins to 11 mins. i was looking for more ways to improve the speed of the demux and realized by moving to an even faster SSD made no difference. it got me thinking whether the DDR3 RAM speed is the factor, or is it the software ie. hali/eac3to etc..

According to Resource Monitor, the eac3to process (during ripbot264 demuxing), is only reading at 50~60MB/s and writing the video.mkv stream at about the same speed. And by moving to an even faster SSD, the SSD utilization does not go up, in fact, it's well under 100%. CPU utilization is less than 5% so it's not really fully utilizing the full potential of the SSD, or the CPU. the only other hardware i can think of would be the RAM. but before i go out and upgrade from DDR3 1866 to DDR3 2600, i just want to make sure that it's not the software.

could someone shed some light on this subject? is it Hali's fault? or is it a hardware limiting factor? my rig is i7 @4.8ghz with Crucial SSD M4 and Crucial MX100, DDR3 1866 16GB. what can i do to farther improve the demuxing speed.

thanks so much!

Reading / writing to the same SSD?

Might be SATA that is the bottleneck.

Test with reading from one ssd and writing to another.

[Atak_Snajpera]

I wonder how big chunks of data does eac3to use during remuxing? Some time ago I had written small benchmark for SSD which test read and copy speed in unbuffered mode.
http://forum.pclab.pl/topic/974463-File-Transfer-Speed-Test/

Here are results for copy speed (Y-axis speed in MiB, X-axis file size in KiB)
http://i.cubeupload.com/IRCQsP.png

As you can see speed is not very good for small chunks of data.

[howzz]

Reading / writing to the same SSD?

Might be SATA that is the bottleneck.

Test with reading from one ssd and writing to another.

i did several tests last night.

one single SSD (7mins:10sec) vs HDD to SSD (7mins:38sec) vs HDD only (23mins:38sec). the source was Casino Royal AVC Blu-ray ISO decrypted from AnydvdHD.

the results were interesting, especially when you factor in MPEG2 source vs AVC source.

with MPEG2, source Alient VS Predator (ISO)
one single SSD (9mins:4sec) vs HDD to SDD (11mins) VS HDD (i didn't bother)

since i only have one SSD on the main machine, which is ICH10 SATA 600. i couldn't test SSD to SSD.

i really don't think it's the SATA bottle-necking, since resource monitor only shows reading from the source at roughly 65MB/s, and writing to the Video.mkv at roughly 55MB, and Audio at about 5~10MB. the thing is, Ripbot or is it EAC3, demux video, audio, and sub all at the same time. would it be faster if the demux process is programmed in series instead of parallel? i am not a programmer, but i am just asking.

[howzz]

I wonder how big chunks of data does eac3to use during remuxing? Some time ago I had written small benchmark for SSD which test read and copy speed in unbuffered mode.
http://forum.pclab.pl/topic/974463-File-Transfer-Speed-Test/

Here are results for copy speed (Y-axis speed in MiB, X-axis file size in KiB)
http://i.cubeupload.com/IRCQsP.png

As you can see speed is not very good for small chunks of data.

Thanks Atak,

nice to see the maker of Ripbot in here.

this is very interesting data. i wonder how small are the chunks that eac3to is dealing with. are they 4K sizes, 1024? etc. because if they're as small as 4K, i might experiment going out and buy the fastest 4K SSD that's out there. but then again, somehow i have doubts that's the culprit.

is it because the way eac3to reads the source?

one thing was interesting last night was if i let DVDFab do the decryption and demux, instead of AnyDVD. DVDFab spits out the demuxed MKV, which contains original video, audio and sub (all passthrough), Ripbot doesn't demux the video.mkv again, it just uses the video straight, and demuxes the audio only, which only takes a 1 minute.

then again, i am always wary about DVDFab, and the way that program runs, which tends to favor speed over quality.

[howzz]

:logfile:
and we can say you how know the culprit.

which log do you want me to post, and where would i go to get to the log file.

[madshi]

eac3to reads 1MB chunks if the source file is any sort of container (e.g. MKV, m2ts or EVO), and it reads 256KB chunks if the source file is anything else (e.g. a separate audio or video track). Writes are done in 1MB chunks. I guess I could increase the read chunk sizes. However, increasing the write chunk sizes is kinda dangerous, because doing so would require me to have a cache in the size of the chunk size of every potential output track. Some Blu-Rays have dozens and dozens of audio and subtitle tracks. Imagine 100 tracks with a chunk size of 16MB. That would already bring us to 1.6GB, and a win32 process is only allowed to allocate 2GB. So increasing the output chunk size can quickly result in out-of-memory situations, if I'm not careful.

There are various possible reasons for slowdown. Of course it's quite possible that some processing filters in eac3to are wasting time. Or it's possible some external software is wasting time (e.g. Haali MKV muxer). Or it's possible that the SSD or the OS is at fault. It's really hard for me to say. A couple tests you could do:

1) Try "eac3to source -check". That will just read the source and demux it, but not encode or write anything.
2) If 1) already shows slow speeds, try a simply "copy" command line command to check how fast that runs through.
3) If 1) already shows slow speeds, try different containers to see if the problem might be specific to one (or several) containers.

[howzz]

eac3to reads 1MB chunks if the source file is any sort of container (e.g. MKV, m2ts or EVO), and it reads 256KB chunks if the source file is anything else (e.g. a separate audio or video track). Writes are done in 1MB chunks. I guess I could increase the read chunk sizes. However, increasing the write chunk sizes is kinda dangerous, because doing so would require me to have a cache in the size of the chunk size of every potential output track. Some Blu-Rays have dozens and dozens of audio and subtitle tracks. Imagine 100 tracks with a chunk size of 16MB. That would already bring us to 1.6GB, and a win32 process is only allowed to allocate 2GB. So increasing the output chunk size can quickly result in out-of-memory situations, if I'm not careful.

There are various possible reasons for slowdown. Of course it's quite possible that some processing filters in eac3to are wasting time. Or it's possible some external software is wasting time (e.g. Haali MKV muxer). Or it's possible that the SSD or the OS is at fault. It's really hard for me to say. A couple tests you could do:

1) Try "eac3to source -check". That will just read the source and demux it, but not encode or write anything.
2) If 1) already shows slow speeds, try a simply "copy" command line command to check how fast that runs through.
3) If 1) already shows slow speeds, try different containers to see if the problem might be specific to one (or several) containers.

thanks Madshi, for the informative response. this really gives a lot of insights into the inner workings.

i'll run some tests when i get home tonight.

can i just say that i support upping the read chunk size. :thanks: at the very least if not the write chunk.

also, i am not sure how many are still running on x86 32bit os, but would it be a possibility to perhaps release a 64bit eac3to that allocates more write cache to get around the 2GB memory allocation issue.

i tend to think that folks who are smart enough to come across eac3to, most likely are running minimum 8GB of ram and 64bit OS. but that's just my guess.

thanks!

[Atak_Snajpera]

I think that 1MiB for read is ok. The problem is most likely in write size. However some cheaper SSDs still need larger size for max speed. Personally I own C100 so I wouldn't mind if read size was increased up to 16 MiB - 64 MiB for max performance.

http://i.cubeupload.com/cRUgvy.png

[73ChargerFan]

Thanks madshi for the update.

I have a question regarding Atmos support. Will eac3to save a THD/Atmos stream as THD without Atmos? Or perhaps the extended Atmos data cannot be removed.