New member needing help with unwanted color space conversions in AVI

[jagabo]

Before you decide for certain that the "fix" is to use rec.709 try some full color artwork, not just green. At least use green and red because rec.709 vs rec.601 effects those oppositely.

[Fox_720]

Well, Vdub didn't work for merging the audio, because it changed the colors once again on the saved AVI. Will try MKV merge next.

[poisondeathray]

Well, Vdub didn't work for merging the audio, because it changed the colors once again on the saved AVI. Will try MKV merge next.

That shouldn't happen. Did you use video=>direct stream copy ?

[jagabo]

VirtualDub always uses a rec.601 matrix to convert YUV/RGB. If you're just remuxing (Video -> Direct Stream Copy) that only effects the display in VirtualDub. The video itself is passed through untouched.

[Fox_720]

Ah! That was it, I guess I missed that. Muxed successfully and the spectrums are identical in Audition.

Strangely, rendering a simple WAV file out of Vegas (16 bit, uncompressed) changes the waveform once again, but if I render to an intermediate AVI with just a blank video track, the audio stays unchanged.

If i direct stream copy the audio from the blank AVI and remux into the meGUI AVI, everything matches up correctly. Next I'll do a quick public audio check and if that turns out good for the channel, I'll stick with this method. I'll share a link with you guys once that's finished so you have the final result. I very much appreciate all that you've done to help solve this frustrating problem.

I wonder if After Effects would be a better program than Vegas. Of course, I can't run AE until I do a system upgrade. I tried once before but my system couldn't hack it.

[poisondeathray]

Strangely, rendering a simple WAV file out of Vegas (16 bit, uncompressed) changes the waveform once again, but if I render to an intermediate AVI with just a blank video track, the audio stays unchanged.

Can you expand this? Not sure what you mean ?

Did you mean the uncompressed WAV out of vegas (audio only) produces different waveform than AVI (blank video) with uncompressed WAV out of vegas ?

How is it different? Some containers and audio encoders might have padding at the beginning (there might be a few ms of padding). This is common with aac and MP4 container

I wonder if After Effects would be a better program than Vegas. Of course, I can't run AE until I do a system upgrade. I tried once before but my system couldn't hack it.

AE isn't a video or audio editor, it's a compositing, effects program. Entirely different purpose . It runs entirely in RGB, but has more advancd color management options (color profiles, ICC, LUTs) than NLE's

[jagabo]

Strangely, rendering a simple WAV file out of Vegas (16 bit, uncompressed) changes the waveform once again

In case you're not aware, WAV can hold compressed audio as well as uncompressed audio. Just because you used WAV doesn't mean the audio was uncompressed. Make sure you really specified uncompressed.

[Fox_720]

Indeed, I specified uncompressed. Here are the settings:

AVI: (ignore the Sony YUV part, that's just the description that I didn't bother changing)


WAV:


Result:

AVI audio spectrum:


WAV audio spectrum:



To see the differences, you'll want to overlay these two images and then switch back and forth. Then it's easier to tell.

[jagabo]

I see the differences in the two spectrum plots but I'm not convinced the two files are different. It may just be a difference in how the software draws the plots. Since the spectrum plots are subsampled the differences may just be alignment. For example, in the AVI file the audio chunks are sized relative to the video frames. So the AVI sample may be slightly shorter or longer than the WAV sample. Notice how the different areas appear at regular intervals. And how the differences are stronger at the right than at the left.

[poisondeathray]

If you want to test that theory, you could extract the audio from the AVI and look at the spectral graph

You might use vdub (file=>save wave), or ffmpeg
ffmpeg -i input.avi -vn -acodec copy output.wav

[jagabo]

If you want to test that theory, you could extract the audio from the AVI and look at the spectral graph

But the extracted WAV may be padded or lopped off at the end. You need to extract then make sure the lengths of the two are equal. Then generate the spectrum graphs. Or better yet, subtract one from the other. Or run a binary comparison on the raw audio samples (which is really the same thing as subtracting). Or zoom in on the waveform view until you can see each sample.

[poisondeathray]

If you want to test that theory, you could extract the audio from the AVI and look at the spectral graph

But the extracted WAV may be padded or lopped off at the end. You need to extract then make sure the lengths of the two are equal. Then generate the spectrum graphs. Or better yet, subtract one from the other. Or run a binary comparison on the raw audio samples (which is really the same thing as subtracting).

Yes, you're right, certain muxers handled the audio differently. For example, ffmpeg's AVI muxer lopped off a few ms from the end.




Some test observations .

- AVI muxing does seem to affect the spectral graph. Different AVI muxers (outside of vegas) will produce slightly different spectral results. I think it might have to do with what jagabo said about alignment or maybe interleaving , or it just might be that audio application parsing or sampling. Some AVI muxers have advanced settings, I don't know how they would affect it

- Extracting the audio from that vegas exported AVI (or any other muxed AVI), doesn't change the spectral analysis afterwards (either by vdub, ffmpeg) - it remains changed from the original audio . Length is the same of the extracted audio compared to original audio

- Re-wrapping the original audio (with blank test video) in MOV using ffmpeg produces identical spectral analysis as original, but vegas exporting to MOV (with blank video) through quicktime doesn't . It might have to do with ffmpeg's MOV muxer is slightly different than quicktime's, maybe just the padding is applied slightly differently



But using MOV for youtube might open up a whole new can of worms for video - read about quicktime quirks, "gamma shift bug"

But this doesn't necessarily indicate anything about how youtube handles containers and audio, the only thing you might conclude from this is this particular audio application handles these containers in this manner...

(My non audiophile ears could not distinguish differences between any of the tests)

I attached a few plots if anyone is interested

[jagabo]

I attached a few plots if anyone is interested

The Vegas video exports all have longer audio. I didn't see it in these samples but it's also possible for the A/V muxer to add a delay for the audio or video, typically to compensate for decoding delays.

[poisondeathray]

I attached a few plots if anyone is interested

The Vegas video exports all have longer audio. I didn't see it in these samples but it's also possible for the A/V muxer to add a delay for the audio or video, typically to compensate for decoding delays.

You're right again, there are a few sample differences

I would have to align them up and re-compare

[poisondeathray]

You're right jagabo - Once they are aligned, they match up perfectly

[Fox_720]

One thing I do notice is that the audio definitely "sounds" different after being passed through Vdub, even with direct stream on. Playing the direct from Vegas extract sounds a little bit more full on the bottom end, whereas after Vdub muxes it, it sounds more full at the top end.

Why would this be so?

I have uploaded an audio comparison test to the youtube channel in question here. I've asked the viewers to weigh in on the audio. In Video A, I used the XDcam codec with uncompressed audio, the one that I am well aware shifts the audio and makes it sound different from the original.

Video B is the one you guys helped me with, using VirtualDub. Most, but not all, hear a difference. Video A has a more full bottom end, the Vdub mux has a fuller top end.

Video A: (XDcam encoded straight from Vegas): http://www.youtube.com/watch?v=hkCydPRMO8s
Video B: (Vdub Muxed): http://www.youtube.com/watch?v=LJk2XGYzUQs

Do you guys have any thoughts on either of these?

[jagabo]

Why would this be so?

Your imagination. I downloaded the two videos. The audio tracks are bit-for-bit identical.

[Fox_720]

Why would this be so?

Your imagination. I downloaded the two videos. The audio tracks are bit-for-bit identical.

I'm not sure it's imagination, however, as many others also hear the difference. Could it be the way youtube plays the video is slightly different? It doesn't make sense that they'd be identical and sound different any other way.

Edit: OK, this is strange. The last time I uploaded XDcam, and then re-downloaded the YT processed video, there was quite the difference in the audio streams. And that was earlier this week. But you're absolutely right, I just downloaded these two and they ARE identical. Perhaps Youtube fixed that problem very recently then?

I still don't understand why people, including myself, hear a difference though.

[hello_hello]

Did you notice for video A, most people thought A sounded better, but for B most people thought B sounded better?

I think it's a case of "tell someone there's a difference" and they'll hear a difference. I didn't download the samples, but they sound identical to me.

[jagabo]

Could it be the way youtube plays the video is slightly different?

I suppose that's possible. How are you comparing? Playing one, then playing the other? Playing both at the same time (muting one)?