Audio Output changes in passthrough

#1
I have installed the trial version of VideoReDo TVSuite V5 (v5.4.84.771) because I've heard it's the best for converting DVR-MS and WTV files into MKV formats. I find the program very easy to use so far and I think I will definitely purchase, the only thing stopping me is I cannot figure out how to get the audio to passthrough.

All the WTV and DVR-MS files I'm trying have a video format of MPEG2 with 1920x1080 at 59.94i (interlaced) video, and the audio stream is AC-3 5.1 audio.

I am loading the video file into the program, and created an output profile for MKV that selects "same as source" for everything, however I can't find an option to do this with the audio encoding, so I select Automatic.
The resulting file properly contains a video the is untouched (but trimmed accordingly), but the audio seems to have been changed, as the metadata shows it as AC-3 5.0 (instead of 5.1). Upon analysis of the file with MediaInfo, the audio stream does contain 6 channels still (Front L C R, Side L R LFE).

So I guess my question is... is this a bug in VideoReDo where it isn't setting the metadata correctly, or am I doing something wrong that's causing the audio to be modified incorrectly?
 

Danr

Administrator
Staff member
#2
In TVSuite V5 we don't recode the AC3 audio which means that if your source is AC3-5.1 the output will be AC3-5.1 unless you trigger a recode. Where are you seeing the metadata as AC-3 5.0?
 
#3
It's being reported in Windows, probably by one of the codecs installed by Shark007. It only appears as 5.0 after going through VideoReDo. I attached 2 screenshots, one where the video is processed through VideoReDo, the other where it goes through DVDFab. You can see the metadata reports correctly for DVDFab, but not from VideoReDo. When either file is looked at in MediaInfo, the readings are identical.

DVDFab.PNG VideoReDo.PNG
 

Danr

Administrator
Staff member
#4
If VideoReDo says 5.1 and MediaInfo says 5.1 then it's 5.1. Could be a different descriptor in the transport stream program map table.
 

Dan203

Senior Developer
Staff member
#5
5.1 and 5.0 are essentially the same. The meta data doesn't actually return 5.1 as the channel count, it just return 5. The way we detect the .1 is by looking at the lfe flag. If it's set then we add a .1 to the channel count. (also applies to 2.1) MediaInfo does the same. Whatever Windows is using is probably just reporting the channel count, and not looking at the lfe flag, which is why it's reporting 5.0.
 
#6
I don't understand then why two files with identical audio are reporting 2 different values depending on what software generated the file. If Windows were looking at the channel count, then the other file would also say 5.0, but it says 5.1.

There must be some kind of stream descriptor or metadata tag that VideoReDo is setting improperly to 5.0 instead of 5.1 even when the LFE channel is there.
 

Dan203

Senior Developer
Staff member
#7
The metadata portion of WTV/DVR-MS is being passed through too, so it's unlikely to be that.

In any case I can assure you that the audio is not being changed. It's impossible. The only way to change the audio would be to recode it and we don't have an AC3 encoder in VideoReDo. The ONLY thing we can do with AC3 audio in v5 is pass it through. If it were being recoded it would be a completely different codec, like AAC.
 
#8
Ok, the audio itself being untouched is consistent with what I'm seeing, but is there no way for VideoReDo to properly "tag" the audio, or whatever it's not doing correctly?
 
#10
That's unfortunate. It is clear VideoReDo is not doing something correctly, because the issue is only there on a file output by VideoReDo. You can't say it's doing nothing wrong when all the evidence shows it is. It's a minor issue, but it's still an issue. Yes, it's bringing the audio through, and yes it plays correctly, but that's not the problem. As a matter of fact, I can take a file produced by VideoReDo, and simply pass it through another program afterwards (I've tried 2 others) and the audio will then show correctly. It essentially strips out the streams and puts in back into a new MKV container and suddenly the data shows correctly. It's only the VideoReDo file that shows wrong. How can that be explained by anything other than the problem lying in VideoReDo?

I was looking for a piece of software which would make it easier to convert these files, and VideoReDo is much easier and quicker, except I can't bring myself to buy it (and I fully intend to if this is solved) if it's not going to set the metadata/descriptor or whatever it's called correctly.
 

Dan203

Senior Developer
Staff member
#11
There is a program that lets you view the metadata for WTV/DVR-MS files. Can you compare the original to the VRD output and see if anything is missing or changed? It has to be a metadata issue as nothing in the actual audio stream is changing. (not possible) The metadata is passthrough too, but there are a few things we manipulate so it's possible we're messing something up.
 
#14
I downloaded and run that tool on several of the files, both WTV and DVR-MS. The program provides a lot of metadata about the recording such as channel, time, program type, etc., but it doesn't show any metadata for the individual streams in the container to see the video or audio contained.
 

Dan203

Senior Developer
Staff member
#15
I downloaded and run that tool on several of the files, both WTV and DVR-MS. The program provides a lot of metadata about the recording such as channel, time, program type, etc., but it doesn't show any metadata for the individual streams in the container to see the video or audio contained.
Hmmm... I'm looking at the code and there "might" be a way to support this that we're currently not doing.

Unfortunately we have no plans to enhance v5 any further, so if I make this change it will only apply to v6.
 
Top