eac3to - audio conversion tool

[madshi]

edit: I understand it right, that the less space consumed by the flac track now is only restricted to 'real' 16-bit trueHD tracks?
The size advantage is only there for anything < 24bit. TrueHD tracks can be 16bit or 24bit or anything in between. Sony uses 20bit for some Blu-Rays. In theory a TrueHD track can even temporarily switch to different bitdepths throughout the movie. But for a full 24bit TrueHD track the new eac3to version doesn't bring any size advantages. However, having dialog normalization turned off is nevertheless an advantage IMHO cause combining "lossless" with "post processing" doesn't really sound like a good idea to me.

[madshi]

A note to all people interested in TrueHD -> FLAC reencoding:

The new eac3to version is brand new and not well tested yet. So I'd suggest that you do some checks to make sure that the results are as expected before you delete the TrueHD file. E.g. a good test would be to check if audio is in sync both in the beginning and end of the movie.

If you've done some testing I'd be thankful for your feedback. A simple note like "worked fine for [x] movies" would be great. Thank you!

[Sephiroth0000]

Madshi I downloaded and used that new EAC3TO you offered for download and now it has worked the file properly and created the WAV. file and then even took it to the 5.1 multi channel WAV. outputs files but it crashes yet again afterwards saying that WavAviMu is not reconised as an eternal command but that's what im supposed to use next. If you look about 2 pages back you should see the error within my bat. command file when it saids it cannot reconise it. Any suggestions please!? (Im so close :))

[Thunderbolt8]

so far I'd say it works fine for fear & loathing HDDVD. although when observing correctly the cpu usage has increased, compared to the -down16 flac file I had used with 1.16. but I guess this is normal :P I havent observed a sync difference between the 1.16 -down16 flac and the 1.17 one.

[madshi]

Madshi I downloaded and used that new EAC3TO you offered for download and now it has worked the file properly and created the WAV. file and then even took it to the 5.1 multi channel WAV. outputs files but it crashes yet again afterwards saying that WavAviMu is not reconised as an eternal command but that's what im supposed to use next. If you look about 2 pages back you should see the error within my bat. command file when it saids it cannot reconise it. Any suggestions please!? (Im so close :))
Can I please see the full output? Is it eac3to which is crashing or is it a program in your batch after eac3to?

[madshi]

so far I'd say it works fine for fear & loathing HDDVD. although when observing correctly the cpu usage has increased, compared to the -down16 flac file I had used with 1.16. but I guess this is normal :P I havent observed a sync difference between the 1.16 -down16 flac and the 1.17 one.
Thanks for the feedback. I've no idea why the CPU usage should increase, but as long as the FLAC sounds correct (and the CPU usage isn't *too* high) I don't think we need to be worried.

P.S: When using "-down16" the resulting FLAC file is really a 16bit FLAC file. The FLAC file created by 1.17 is a 24bit FLAC file. This might explain the difference in CPU usage. But the file sizes should be roughly similar. How big is your 1.16 -down16 FLAC file in comparison to the 1.17 one?

[Sephiroth0000]

C:\HD>wavavimux -o audio.avi -iwav 6 output-FL.wav output-FR.wav output-C.wav ou
tput-LFE.wav output-SL.wav output-SR.wav -mask 63
'wavavimux' is not recognized as an internal or external command,
operable program or batch file.


That is the error I get after the audio process has completed. I did check that the WavAviMux is on my system and it is(c:\programs folder\windows media encoder\components\WAVAVIMUX\WavAviMux.exe) but for some reason it saids that it is not a reconised command or something. Im so close to sealing this. Thankyou for the input I really do appreciate it.

[madshi]

C:\HD>wavavimux -o audio.avi -iwav 6 output-FL.wav output-FR.wav output-C.wav ou
tput-LFE.wav output-SL.wav output-SR.wav -mask 63
'wavavimux' is not recognized as an internal or external command,
operable program or batch file.

That is the error I get after the audio process has completed. I did check that the WavAviMux is on my system and it is(c:\programs folder\windows media encoder\components\WAVAVIMUX\WavAviMux.exe) but for some reason it saids that it is not a reconised command or something. Im so close to sealing this. Thankyou for the input I really do appreciate it.
Well, it seems that you've now successfully passed the eac3to step. That's really all I know about. I've never used WavAviMux myself yet. But the reason why it fails for you is probably that WavAviMux.exe is in a folder the batch file doesn't know about. In your batch file try adding the full path to WavAviMux.exe. You might have to put the whole path+exe in "".

[Thunderbolt8]

How big is your 1.16 -down16 FLAC file in comparison to the 1.17 one?
0.98GB: 1.16 -down16 file
2.8GB: normal 1.16
2.8GB: normal 1.17 file (both exact same size)
3.29GB: rebuilt .evo (contains only the 5.1 trueHD track)

[madshi]

both have exactly the same size
Ah, ok, that's nice.

[Thunderbolt8]

sorry, had to edit, mixed things up :P
seems like fear and loathing is a "true" 24-bit file, so the filesize didnt change, but only dialog normalization removed?

[madshi]

sorry, had to edit, mixed things up :P
seems like fear and loathing is a "true" 24-bit file, so the filesize didnt change, but only dialog normalization removed?
Yep...

[Rectal Prolapse]

madshi - wow, amazing stuff. I think you did the impossible by defeating dialnorm. Congratulations and I can't wait to try it out (when I find more titles with TrueHD!)

Thanks for such a great tool!

[madshi]

I think you did the impossible by defeating dialnorm.
Well, it was not impossible, but really difficult. Just finding and changing the dialnorm field in the TrueHD headers was not even the problem. The main problem was that the TrueHD headers are protected by a checksum (CRC). So I had to find out how this CRC is calculated. It's quite hard to figure such stuff out without having an official documentation...

[TheSof]

I'm having some trouble with the latest version. With the previous version, I went .thd => flac, no problems except for the dial norm.

Now, the same .thd file throws "The source file format is unknown".

[markrb]

Is there any benefit to using the TrueHD source over the DDP if my final mux source will be as an ac3 file?

Thanks,
Mark

[madshi]

I'm having some trouble with the latest version. With the previous version, I went .thd => flac, no problems except for the dial norm.

Now, the same .thd file throws "The source file format is unknown".
Yeah, I noticed this problem, too. Sometimes demuxed TrueHD files have some "garbage" bytes in front of the real data. Don't know why. eac3to doesn't like this. The next version will fix that.

[madshi]

Is there any benefit to using the TrueHD source over the DDP if my final mux source will be as an ac3 file?
When encoding and especially when reencoding it's the best solution to always use the highest quality source you can get. So the question is: Do TrueHD files have a better audio quality compared to DDP files? Well, that question may be harder than you think. Most people would say yes. However, DDP files are 24bit while most HD DVD TrueHD tracks are only 16bit. It's not totally clear whether DDP files with 1.5Mbps sound better or worse than 16bit TrueHD tracks. The insiders don't really agree there, either.

What is clear is that if the TrueHD track has more than 16bit, it's definitely the way to go. And if the DDP track has less than 1.5Mbps then the TrueHD track is also the way to go. If the TrueHD track is 16bit and the DDP track is 1.5Mbps then I don't know what to recommend...

[madshi]

eac3to v1.18 released

http://madshi.net/eac3to.zip

* bugfix: some TrueHD files were not accepted ("The source file format is unknown")
* change: EVO files are not accepted as source files, anymore
* added: detection and repacking of 16 bit TrueHD tracks
* added: proper detection of "DTS-HD Master Audio" and "DTS-HD High Resolution" tracks
* added: runtime information for "DTS-HD High Resolution" tracks
* bugfix: bitrate information for "DTS-HD High Resolution" tracks
* added: decoding of "DTS-HD Master Audio" tracks (Sonic)
* added: decoding of "DTS-HD High Resolution" tracks (Sonic)
* added: decoding of conventional DTS tracks (Sonic/Nero)
*** full DTS-HD decoding support ***

I think this is another very big release because of full "DTS-HD Master Audio" and "DTS-HD High Resolution" support! But actually I've not done much to make that work. It's just that I found out that the Sonic Audio Decoder can already decode DTS-HD just fine! So I just added automation for that.

Please reread the first post of this thread. I've added/corrected a lot of information there.

Basically a quick summary would be: "DTS-HD Master Audio" decoding should work bit perfectly (I cannot check if it's really bit perfect, though, I'm just guessing from what I can see). So reencoding to FLAC would make a lot of sense. "DTS-HD High Resolution" decoding works mostly fine, too (details see first post). Of course the big question with "DTS-HD High Resolution" is: Into which format should we reencode this to (especially with 24bit tracks)? Reencoding to FLAC would greatly increase file size. Reencoding to anything else doesn't make much sense. Instead we could just extract the DTS core and be done with it. Fortunately most DTS-HD tracks from HD DVD and all DTS-HD tracks from Blu-Ray are lossless (DTS-HD Master Audio). And for those FLAC reencoding should be perfect.

There's one change for TrueHD decoding: Basically eac3to now checks (after decoding) whether the decoded data contains only 16 bits of information or more than that. If there are only 16 bits of information in the raw 24 bit file, eac3to strips the zero bytes and reduces the raw file to 16 bit. This was not really all that necessary. I've compared and the space saving when encoding in FLAC is only about 0.1 percent. However, I just found it cleaner to have 16bit TrueHD tracks encoded in 16bit FLAC instead of 24bit FLAC. Anyway... Interestingly, I also compared DTS and AC3 encoding and the resulting DTS and AC3 files were bit identical, regardless of whether I stripped the zero bytes or not! Huh, I didn't expect that... :) There's a big saving if you reencode a 16bit TrueHD file to WAV, of course. But who does that? :)

Here are some quick checks with DTS-HD decoding/reencoding:

Eragon Blu-Ray, DTS-HD Master Audio, 24 bit:
- runtime 00:09:15
- 1.5Mbps dts core: 100.0 MB
- dtshd file: 267.5 MB
- reencoded to 24bit FLAC: 230.2 MB

Pan's Labyrinth HD DVD, DTS-HD Master Audio, 16 bit:
- runtime 00:09:15
- 1.5Mbps dts core: 100.0 MB
- dtshd file: 128.5 MB
- reencoded to 16bit FLAC: 77.5 MB

Perfume HD DVD, DTS-HD High Resolution, 16 bit:
- runtime 00:09:15
- 1.5Mbps dts core: 100.0 MB
- dtshd file: 134.9 MB
- reencoded to 16bit FLAC: 110.2 MB

I think these are very interesting results! It's clear to see that 24bit lossless compression (Eragon) comes at a big price. DTS-HD Master Audio compression compares "ok" to FLAC here. With 16bit lossless compression FLAC even beats the 1.5Mbps DTS core in file size! DTS-HD Master Audio compression again works "ok" compared to the DTS core. But it's quite clear that for 16bit movie tracks lossless compression is actually a great idea! It's just too bad that lossless compression works noticably worse as soon as you go above 16bit.

It should be added that lossless compression efficiency depends a lot on the audio data. If there's not much happening in the audio track, lossless compression can work very well. You can compare that to how zip behaves: With text files zip reaches extreme compression ratios. But try to compress an EXE file and the compression ratio goes noticably down. The same thing is true with lossless audio compression (FLAC, TrueHD, DTS-HD Master Audio). In comparison the lossy codecs (AC3, E-AC3, DTS and DTS-HD High Resolution) always consume the same space. The audio track file size only depends on the constant bitrate and on the movie runtime. So depending on the movie lossless codecs can sometimes beat lossy codecs in file size. That's especially true for 16bit tracks. But as soon as you go above 16bit, the situation changes dramatically because lossless compression is just much less efficient for more than 16bit (because there's more noise in the additional bit and noise is difficult to compress losslessly).

[hristoff2]

Oh snap! :devil: :)

btw. do we need to use Sonic 4.2 Audio Decoder or 4.3 for DTS-HD decoding? (I remember sth about 4.3 decoding TrueHD badly - but at least it can decode it, so they updated sth)

[madshi]

I'm not sure, personally I'm using 4.3.

[Thunderbolt8]

so I guess apart from that dts-hd high resolution, which is inferior to dts-hd master anyway and also only rarely used, eac3to can convert anything else from blue-rays/hddvds bit per bit perfectly now (to flac)?

:thanks:

[Taktaal]

Madshi I downloaded and used that new EAC3TO you offered for download and now it has worked the file properly and created the WAV. file and then even took it to the 5.1 multi channel WAV. outputs files but it crashes yet again afterwards saying that WavAviMu is not reconised as an eternal command but that's what im supposed to use next. If you look about 2 pages back you should see the error within my bat. command file when it saids it cannot reconise it. Any suggestions please!? (Im so close :))

Which codec did you use to convert the DDP? Nero or Sonic?
How did you fix the 0 byte expected error?

[madshi]

so I guess apart from that dts-hd high resolution, which is inferior to dts-hd master anyway and also only rarely used, eac3to can convert anything else from blue-rays/hddvds bit per bit perfectly now (to flac)?
Yes, I think so... :)

As I mentioned before, I've no way to check if the Sonic DTS-HD Master Audio decoding is bit perfect, but it seems like that. At least there's definitely no dialnorm and no DRC applied. And the Sonic decoder definitely gives out a different result for the DTS-HD Master Audio track compared to if you only feed it the DTS core of the same track. So it looks like being bit perfect.

[Thunderbolt8]

tested the trueHD decoding once again with fear & loathing.

3.10 GB = demuxed trueHD track
5.71 GB = raw file size
2.80 GB = FLAC file size (cant tell though if size was byte
identical with the one produced yesterday with v1.17)

"this track contains more than 16-bit of information" so we have a true 24-bit (or at least 20-bit or something like that) track here on the fear & loathing HDDVD :)

[madshi]

tested the trueHD decoding once again with fear & loathing.

3.10 GB = demuxed trueHD track
5.71 GB = raw file size
2.80 GB = FLAC file size (cant tell though if size was byte
identical with the one produced yesterday with v1.17)

"this track contains more than 16-bit of information" so we have a true 24-bit (or at least 20-bit or something like that) track here on the fear & loathing HDDVD :)
Good. Looks like things are working as expected... :)

[Thunderbolt8]

hm is it possible that the 24-bit FLAC from truehd 5.1 is very slightly out of sync? the one I created for fear & loathing now seems to be a tiny bit, I also believe it was a little better with the former versions. I muxed the flac into .mka and then muxed this together with the video with a 23.9760239 fps timecode .txt file into .mkv
I tested it with ffdshow and also the WMVideo DMO decoder (which uses less cpu performance, because its distributed to both cores; cpu usage for each core is <50 % according to task manager), same result for both (using coreflac btw.)

[madshi]

I've also noticed that I needed to add 200ms delay to my main test FLAC. I'm not sure why that is the case. I'm very sure that this is not a bug in eac3to. I guess that demuxing the TrueHD track loses timecode information which results in this slight audio delay. I don't think it's a big issue, though. Of course we'll need to check and eventually correct audio sync for all TrueHD -> FLAC files and probably also all DTS-HD -> FLAC files now. Oh well, probably that means that I need to write a tool which can apply delays to FLAC tracks! Shouldn't be difficult, fortunately. Maybe sooner or later we'll find a way to calculate the necessary delay? That would be more comfortable, of course.

So everybody who's using the new TrueHD/DTS-HD -> FLAC reencoding: Please check which delay you need to apply and try to find out whether this delay seems to relate somehow to the EVO timestamps (which you can read out with EvoDemux). If we can find out how to calculate the delay, that would be great!

[Thunderbolt8]

im not that familiar with all that technical stuff, how can I manage to find out the evo timestamps with evodemux?
and since you only mentioned truehd and dts-hd now, could this delay thing also happen when remuxing eac3 tracks to flac?

as it seems the delay needed for fear & loathing also needs to be between 175 and 225 ms

[madshi]

Check out the "PTM" of the first video frame and compare that to the "First PTS" of the TrueHD/DTS-HD/E-AC3 audio track in EvoDemux. If these are identical, there should be no audio delay necessary. If they differ, we might need an audio delay. This should be valid for any demuxed audio track, I think. EvoDemux should show the necessary delay. However, for negative delays EvoDemux doesn't show the correct value but a very big positive number instead.

P.S: Or maybe the "First PTS" of the audio track is the delay we need - independently of what the "PTM" of the first video frame sais?

These PTM and PTS values are hexadecimal values. That means: Start calc.exe, switch it to hexa mode, then enter that hex number. Then convert to decimal. Now divide the decimal number by 90 and you get milliseconds. E.g. hex "000034C8" is decimal "13512", divided by 90 is about "+150ms".

[Thunderbolt8]

values are identical for the video stream and all audio tracks on that disc. I ran offsetpts before rebuilding the video evo, but it told me that offset was fine and didnt need to be processed

edit: wait, lol, this does only apply for the 1st evo file. for the 2nd evo file theres a difference, mom


Opening file FEATURE_1.EVO

PTM of first video frame = 00000D8E
Dolby TrueHD audio stream 0 found!
First PTS = 00000D8E



Opening file FEATURE_2.EVO

PTM of first video frame = 125C7D0A
Dolby TrueHD audio stream 0 found!
First PTS = 125C438F (+3422589ms)

(3 of the 4 audio tracks of the 2nd evo have a different delay btw, only the delay of the 2 DD+ 2.0 tracks is the same)

125C7D0A - 125C438F = 397B = 14715 : 90 = 163,5 <-- the delay needed ? (if yes, for the 2nd .evo file only though)


btw. I still have a remux with the v1.17 created flac file from that trueHD track and the sync issue there in the 2nd half of the movie is NOT present. so I guess it must be some little mistake which got in when you made the latest changes maybe.

watched the same scene over and over again, still, the 1.17 version is either complete identical with the evo or has a delay of <20ms or such, which I cant really spot any more. at least I believe they are identical and other thoughts might as well just come from having this watched already too often now. the 1.18 version however, although I set the delay to the above calculated 163ms in mkvmerge now, is STILL A LITTLE out of sync. it has gotten better compared to a remux without any delay before or compared to my attempts to sync it manually, but its still a bit noticeable, compared to the original evo and the 1.17 remux.

[Roscoe62]

This is probably a tiny bit off topic, but I haven't been able to figure out how to find the "right" audio track to extract when I use xport. I know in the command line you have to specify which program number, video track & audio track you wish to extract, but how do I determine which ones are correct?

I'm guessing there's a method to it, but after searching around the forum I still haven't managed to find the answers.

Sorry for the noob question, but with eac3to doing such a fantastic job of the audio (thanks again Madshi! - eac3to is turning into a regular swiss army knife for audio!) my lack of understanding of how to correctly use xport is the only thing slowing me down.

Can anyone point me to a guide, or help me to find what I'm looking for?

Thanks!

[Thunderbolt8]

well yes, it would be nice to have a counterpart to evodemux just for blue ray :P

[Sephiroth0000]

Which codec did you use to convert the DDP? Nero or Sonic?
How did you fix the 0 byte expected error?


Taktall all I done was loaded the new EAC320 up to the folder that contained all the video, audio, grf and avi files and then loaded up the EAC320GUI (must have EAC320 file there to use properly) It actually does the convert for you. I have downgraded my Nero 8 to Nero 7.10.0.1 with the HD BluRay plugin aswell so I do not know if that makes a difference. Oh and also EAC320 GUI lets you force the encoder use so you can use Nero directly which is good to do if you ask me. Oh and WAVAVIMUX you must install it to the folder you are working from NOT WINDOWS MEDIA ENCODER.

[Sephiroth0000]

Im really coming close to getting this done properly everyone (EVO to WMV HD with 5.1) And when I do I shall be adding my own tutorial on how to do it and it will be dummy proof :)
(YES even I got stuck on doing this ha, ha, ha

[Thunderbolt8]

another thing, I tried to install the illiminable_flac decoder to see if hes better/faster than the coreflac decoder, using this download link here:
http://rapidshare.com/files/9974707/illiminable_flac_0.73.1936.exe.html

but after the installation & restart of windows I still dont seem to be able to use it, at least I cant find it as external filter in mpc. did I do something wrong or am I just blind?

[madshi]

edit: wait, lol, this does only apply for the 1st evo file. for the 2nd evo file theres a difference, mom
That shouldn't matter.

btw. I still have a remux with the v1.17 created flac file from that trueHD track and the sync issue there in the 2nd half of the movie is NOT present.
Wait a moment! So your sync problem is only in one half of the movie? I think you didn't say that before, or did I miss that? For me, after using a delay the sync works throughout the full movie.

watched the same scene over and over again, still, the 1.17 version is either complete identical with the evo or has a delay of <20ms or such, which I cant really spot any more.
That's really very strange... I can't see why 1.17 and 1.18 should behave differently!! You did use 1.17 with the *demuxed* TrueHD track, didn't you? Or did you feed the TrueHD evo file to 1.17? That would explain the difference...

the 1.18 version however, although I set the delay to the above calculated 163ms in mkvmerge now, is STILL A LITTLE out of sync. it has gotten better compared to a remux without any delay before or compared to my attempts to sync it manually, but its still a bit noticeable, compared to the original evo and the 1.17 remux.
The calculated delay is all wrong. The timecode values of the 2nd EVO file have no meaning.

[madshi]

This is probably a tiny bit off topic, but I haven't been able to figure out how to find the "right" audio track to extract when I use xport. I know in the command line you have to specify which program number, video track & audio track you wish to extract, but how do I determine which ones are correct?
Personally, I'm using TsRemux to see which audio tracks are in the m2ts files in which order. The first audio track is usually number 1, the 2nd audio track number 2 etc. The I use xport for demuxing, using the numbers I've taken from TsRemux.

[Thunderbolt8]

after watching again, I'd say the delay problem with the 1.18 file also happens in the 1st half of the movie. before I just didnt bother to check it properly enough, because I though it would only apply to the 2nd (evo) half, but as it seems there is also a slight delay present in the 1st half with no delay entered at the muxing stage.

and yes, I used a rebuilt evo (that audio track only) for the 1.17 muxing, because since remuxing and rebuilding both takes ~same time and when demuxing he would have to remux it temporarely into an evo file anyway again for the flac conversion, I thought I just save myself that time. just not possible any more in 1.18 :P

dont have further time to test things throughout the day today as it seems. maybe a bit more time in the evening but cant say that for sure.

[ACrowley]

another thing, I tried to install the illiminable_flac decoder to see if hes better/faster than the coreflac decoder, using this download link here:
http://rapidshare.com/files/9974707/illiminable_flac_0.73.1936.exe.html

but after the installation & restart of windows I still dont seem to be able to use it, at least I cant find it as external filter in mpc. did I do something wrong or am I just blind?

Thats correct..the Decoder is not listed in Directshow. Only the native FLAC Source Filter.
But any Dshow Player should select the Decoder without Problmes.

Note :
illiminable FLAC Decoder cat handle FLAC in mkv container!
So use ffdshow for FLAC in Ciontainer and illiminable for single FLAC Files

[Thunderbolt8]

ffdshow is too slow as I have noticed. though I can still play any 1080p, with ffdshow as it seems theres a little delay sometimes, which is not present when using coreflac. and because of that conversion problem here with the flac delay I thought maybe coreflac is too slow either and tried to find a faster decoder for .mkv files with mpc.

[ACrowley]

ffdshow is too slow as I have noticed. though I can still play any 1080p, with ffdshow as it seems theres a little delay sometimes, which is not present when using coreflac. and because of that conversion problem here with the flac delay I thought maybe coreflac is too slow either and tried to find a faster decoder for .mkv files with mpc.


You should use only the ffdshow AudioDecoder for FLAC in mkv...i wasnt talking about the VideoDecoder.
Thats another Thing...

[Thunderbolt8]

thats what I mean, the audiodecoder :P
im using ffdshow video anyway, but when also using ffdshow audio to decode flac sometimes a little audio delay can occur, which is not present with coreflac.

[ACrowley]

thats what I mean, the audiodecoder :P
im using ffdshow video anyway, but when also using ffdshow audio to decode flac sometimes a little audio delay can occur, which is not present with coreflac.


I never had any Delay with ffdshow Audio decoder.
Try to use 16bit output...dont think it use lot of CPU usage and a DualCore can handle it
I dont like Coreflac cause it wont connect to AC3 Filter. I use AC3Filter in the decoding chain fro flac to get AC3 640 Output ( which sound s still great)

@Madshi
Great Work!!
TrueHD decoding on demuxed Files and without DialogNorm !! Wow!
And full dts hd decoding...wonderfull!

But ive Problems with the dtshd Tracks Perfume HDDVD. eac3to shows the Information and stops...the dtshd must be little bit corrupted .
I demxued both dtshd via Graphedit beacause there where Problmes with evodemux. The extracted core was cracking, you know...
So eac3to 1.18 stops decoding bad dtshd Tracks too ?

[Sephiroth0000]

Do not know if anyone can lend a helping hand to this but I am getting the following error with my Avisynth video only file when I try to play it

DIRECTSHOWSOURCE: GRF file does not have a compatiable open video pin. Graph must have 1 output pin that will bid RGB24, RGB32, ARGB, YUY2 or YV12

Now apart from this error I have mastered everything with regards to making a HD DVD evo image into WMV HD with 5.1 (Yes the audio has been mastered) Someone help !

[Taktaal]

Has anyone actually been able to get the Sonic Decoder to work with an eac3to version after 1.12? After reading this thread and the older EVOdemux one, I think that's when the support broke.

[Sephiroth0000]

Has anyone actually been able to get the Sonic Decoder to work with an eac3to version after 1.12? After reading this thread and the older EVOdemux one, I think that's when the support broke.


Taktall what is it you are trying to do? I assume it is with Audio maybe I can help.

[ACrowley]

Do not know if anyone can lend a helping hand to this but I am getting the following error with my Avisynth video only file when I try to play it

DIRECTSHOWSOURCE: GRF file does not have a compatiable open video pin. Graph must have 1 output pin that will bid RGB24, RGB32, ARGB, YUY2 or YV12

Now apart from this error I have mastered everything with regards to making a HD DVD evo image into WMV HD with 5.1 (Yes the audio has been mastered) Someone help !

Set :

HKEY_LOCAL_MACHINE\SOFTWARE\Sonic\CommonMPEGDecoders\4.2\VideoDecoder

AllowAllRenderers to 1

Then you can use the VideoDecoder 4.3 as usual via Directshowsource in Avisynth :)

[madshi]

after watching again, I'd say the delay problem with the 1.18 file also happens in the 1st half of the movie. before I just didnt bother to check it properly enough, because I though it would only apply to the 2nd (evo) half, but as it seems there is also a slight delay present in the 1st half with no delay entered at the muxing stage.
Ok, that's actually good because that means that probably the audio is in sync throughout the whole movie, as soon as you apply the correct delay to the FLAC file. It's the same with some E-AC3 files. Not all of them are automatically perfectly in sync, either. If audio sync was correct in one half of the movie, but out of sync in the other half, that would be a much tougher problem to crack!

and yes, I used a rebuilt evo (that audio track only) for the 1.17 muxing, because since remuxing and rebuilding both takes ~same time and when demuxing he would have to remux it temporarely into an evo file anyway again for the flac conversion, I thought I just save myself that time. just not possible any more in 1.18 :P
The main reason why I removed EVO input support in 1.18 was because the dialnorm removal only works with demuxed TrueHD files. So the TrueHD track you converted with 1.17 still has dialnorm applied. When creating v1.18 I noticed that I didn't clearly say that EVO input should no longer be used. And even if I documented that in 1.18 I feared that some people wouldn't read the documentation properly. So I just removed EVO input to force all people to use the proper way to have dialnorm defeated.

Sorry, my fault, should have clearly said that EVO input is not recommended, anymore (when releasing v1.17).

[madshi]

But ive Problems with the dtshd Tracks Perfume HDDVD. eac3to shows the Information and stops...the dtshd must be little bit corrupted .
I demxued both dtshd via Graphedit beacause there where Problmes with evodemux. The extracted core was cracking, you know...
So eac3to 1.18 stops decoding bad dtshd Tracks too ?
I'm not sure. I think 1.18 should just complain about the dirty track, but try to continue. Maybe the audio decoder stopped? How does the full text output look like?

Anyway, you can avoid to have a corrupted audio file in the first place. EvoDemux has a bug with Perfume. I fear if you have rebuilt the DTS-HD tracks into a separate EVO file you might already have corrupted the audio files. Try demuxing the original EVO file by using drmpeg's EVO demuxer. Here's the download link:

http://www.w6rz.net/evob_demux.zip

Using that instead of EvoDemux for Perfume results in perfectly clean DTS-HD tracks. Unfortunately Perfume only has DTS-HD High Resolution tracks encoded from a 16bit master. So the Sonic audio decoder forcefully downconverts to 16bit. I'm not sure which is better: DTS-HD High Resolution downconverted to 16bit (Sonic) or just the core, but with full 24bit (Nero).