Blu RAy AC3 import problems...

MPM wrote on 7/6/2008, 4:34 PM
I’ve been playing with the Blu Ray audio handling in DVDA 5, trying to nail down a bit how it’s broken & potential work-a-rounds... Right now my best guess is that on top of new, relatively unproven code (that itself has problems), the developers also overlooked Intel Endian AC3 files when writing it.

I’m fairly sure that there’s some problems with the code itself: on a test project, trying out various media, DVDA5 would not accept a Vegas encoded AC3 as compliant, even though it had no problems with the exact same file in a new Blu Ray project. Once the DVDA index file was written in the new project, the old one would take it as well, so the problem would be with the code for parsing imported media - not a huge surprise since this part of DVDA has always been it’s weakest IMHO, often giving odd problems importing non-Vegas media in older versions.

Unfortunately while there’s plenty of software for encoding/decoding ac3, I couldn’t find any good stuff this afternoon for analyzing existing files, so Intel Endian AC3 causing problems with good AC3 files being non-complaint in a DVDA5 Blu Ray project is a guess... but a guess based on nothing else appearing to be wrong with the audio files, plus Vegas rendered AC3 with Intel Endian checked in the custom dialog behaved the same way.

Nothing short of re-encoding the problem AC3s helped - re-writing, trimming, fix-it utilities etc. all had no effect. I couldn’t find one, but if anyone finds or knows of a utility to change a Big Endian file to a Little Endian version without re-encoding, please post it in the forum as I’m sure it’ll help a lot of folks until SCS patches their code... On a regular DVD, DVDA doesn’t have any problems, other than an initial delay importing the same AC3 file rejected for Blu Ray.

Thanks...
Now back to trying to gather more info on why I can get DVDA5 to include only 3 minutes out of a 1.5 hour video in a Blu Ray project. ;-)

Comments

Wolfgang S. wrote on 7/6/2008, 11:24 PM
What is a known issue is, that the AC3 Studio encoder delivers AC3 streams, that are recompressed in DVDA5. However, the AC3 Pro encoder delivers streams that are not recompresse at all (at least not what I have seen).

Desktop: PC AMD 3960X, 24x3,8 Mhz * RTX 3080 Ti (12 GB)* Blackmagic Extreme 4K 12G * QNAP Max8 10 Gb Lan * Resolve Studio 18 * Edius X* Blackmagic Pocket 6K/6K Pro, EVA1, FS7

Laptop: ProArt Studiobook 16 OLED * internal HDR preview * i9 12900H with i-GPU Iris XE * 32 GB Ram) * Geforce RTX 3070 TI 8GB * internal HDR preview on the laptop monitor * Blackmagic Ultrastudio 4K mini

HDR monitor: ProArt Monitor PA32 UCG-K 1600 nits, Atomos Sumo

Others: Edius NX (Canopus NX)-card in an old XP-System. Edius 4.6 and other systems

MPM wrote on 7/7/2008, 6:22 AM
Hmmm... once I get a chance to better nail down what the mpg2 requirements are I'll try importing more ac3 to double check - so far any ac3 from Vegas pro imported OK into a new Blu Ray project. The studio encoder doesn't give you the custom options for ac3 render like the regular ac3 renderer, so I don't know what the default Endian type is for that one. Since I was just running test after test, I ran the studio encoder immediately "After" encoding an AC3 file in the normal fashion... the speed of the studio encoder leads me to believe that Vegas might have just copied the ac3 I had already rendered. It's possible that the studio encoder renders Intel Endian files if that's the 1st & only ac3 encoder you use.

If so, than I'd imagine it's something else for SCS to patch. To me it doesn't make sense that they'd use a different Endian order as default for the studio encoder, but then it doesn't make sense either that DVDA5 would accept an ac3 file for a regular DVD, then reject it for a Blu Ray version! If the problem is someone overlooked the Endian order, I'd imagine SCS would want to fix it pretty quickly - hardware encoders (cameras etc) seem to use the Intel order more often.

I've read that DVDLab Pro indicates the Endian order for imported AC3 files, so importing problem ac3 files, including those from Vegas' studio encoder might be the next thing to do? As it is I know something's broken, because as I mentioned DVDA5 rated an AC3 file as not compliant when substituting that file for another 1 that DVDA considered bad - the same ac3 was accepted into a new Blu Ray project - after the DVDA index file was written in the new project, the original project (the 1 with the bad ac3) accepted the ac3 file as good.

Since there doesn't seem to be an easy way to convert Endian orders without re-encoding the file, & since there appears to be code that needs fixing anyway, I stopped, deciding to next look at mpg2 where there are some definite, maybe more serious problems in the code - 1 problem is that it will sometimes only include a few minutes worth of mpg2 video (that DVDA5 deems compliant) on a Blu Ray disc or image. I'm also trying to find mpg2 it won't accept. Hopefully there will be a quick and easy fix for mpg2 files - I'm less confidant that end of things will be repaired, or repaired as quickly since for several years DVDA has been quirky about working well with m2v streams from outside Vegas.

Oh well, when I have a chance I'll dig deeper... And there's also AVC to look at - hopefully no problems there.

Thanks much for the input Wolfgang. :?)
ECB wrote on 7/7/2008, 7:31 AM
It looks to me that DVDA5 BD will only accept ac3 with a bit rate 448 no matter what bit rate you set in the Properties.

Ed
MPM wrote on 7/7/2008, 12:18 PM
I got it to accept several bit rates - I tried maybe half a dozen. As long as it accepted the ac3 as compliant, the project bit rate didn't matter -- if it didn't accept the ac3, then it used the project setting to re-encode. And re-encoding ac3 is not something you want to do in DVDA - it's slower, doesn't make good use of multi-core CPUs, and since it insists on creating images [ *&!@$#!!! grumble snarl ] , you have to re-encode for every render.
alk3997 wrote on 7/8/2008, 9:31 AM
Also another reason not to re-encode is that AC3 is lossy audio. Anytime you re-encode, even if it is just changing bit rates, will result in an even greater difference between the original and the final AC3.

Andy