1Q...

how and what kind of capturing HW r u using ? some kind of a capture card ? analog 2 dv converter ?

honestly i´m checking this thread with great interrest...in between jobs :)
BT

My goodness,
if anyone had bothered to read the whole of this thread instead of grabbing something half way through they'd have seen that we've already done detailed analysis of this problem.
a) The AVI file as recorded by VidCap is 16/32K period. This has been verified by opening it with SF7 which reports the audio as 16/48K.
b) During capture it's bleeding obvious something is wrong as the audio sounds horrible due to sample rate errors. Vidcap is sending 16/32K audio to the sound card that's been told it's 16/48K. Sure it sounds OK when you play it back as then Vegas resamples it.
c) The same tapes captured with SCLive produce an AVI file containing 16/48K audio.
d) Problem occurs with multiple tapes played in various devices, it occurs not only with DV and DVCAM tapes but with Digital Betacam tapes played in Sony J30 decks via firewire.
e) Same tapes played out of same decks into another device cause the recording device to report incoming audio on firewire to be 16/48K.
Clearly something is wrong with VidCap and how it works with various decks and cameras, possibly this only happens in PAL land. The problem doesn't not occur EVERY time though. At times I can capture audio at 16/48K from the same decks using VidCap.
Bob.

...possibly this only happens in PAL land.

Bob, you mean like the time code bug that drove Leslie crazy?
Some times it's good to be in NTSC land :-)

Mike

The AVI file as recorded by VidCap is 16/32K period. This has been verified by opening it with SF7 which reports the audio as 16/48K.

Bob, could you clarify that?

It appears that the deck is trying to make the most of the DigiBeta audio tracks by squeezing them into 16/32kHz, which afaik is not a supported DV standard, so it seems reasonable that Sony didn't write code for it. Or am I missing something?

THanks Farss.

Yes, it did seem we were playing helipcopter.

Hopefully, the team does read the thread in a logical order...

It seems no one has the solution - even SONY, I'll just have to make do with SC Live for future capture...

Bit

Pretty simple.
Open AVI file with SF7 and it says the audio is 16/32K.

Yes DB records audio at 24/48K, the J30 decks send the audio as 16/48K UNLESS you ask it to send 4 channels in which case it sends 12/32K, this is configured via the decks menu. However we've configured the decks to send channels 1/2 and independently verfied that they do send 16/48K. That is unless you capture them with VidCap, in which case you get 16/32K, use SCLive and you get 16/48K.

The one thing that we don't know is if VidCap is screwing with the audio sampling OR is VidCap sending an erroneous command to the various decks and cameras causing them to send audio as 16/32K. To resolve that I'd need as 1394 sniffer, we do have two SD Connects which can do just that but I'd need to make a1394 "Y" cable and I don't know if the SD Connect will display the audio sample rate data in sniffer mode.

Important point to note here, DV audio is supposed to be either 16/48K OR 12/32K and I'm 99% certain that when this problem occurs we get 16/48K audio which is VERY odd. If you actually capture 12/32K audio from a tape recorded with that then Vegas builds a proxy file (12/32K uses a non linear quantization which uses a lot of CPU to decode), in this case that does not happen, ergo the audio is definately 16/32K.

Bob.

I wonder if other Vegas users have issues with this audio thing..?

Bit

No, not yet. Works fine here. What I usually use is:

- Various DV decks and DV cameras from which the capturing is done through firewire.

- Analog resources like BetaSP/DigiBeta/IMX which is captured by using various AD converters.

- DAT device attached to a Terratec EWX 24/96 soundcard via TOS link.

- Mikrophones/Instruments attached to a Tascam US-122 external soundcard.

In any of these cases I never had a problem/change with/of the audio properties.

Marco

Thing is it's not exactly an obvious problem. Unless you monitor the audio during capture and noticed it sounds pretty bad or actually check the media properties you wouldn't know it'd gone wrong. I'd noticed the audio sounded pretty cruddy during capture for ages, just wrote it off as being one of those things that I didn't need to worry about as it sounded just fine when I played it back from the T/L.
Also of course one rarely has stellar audio on camera tapes, I really doubt if the resampling down to 32K and back up again is anything to sweat about.
But lately I'm working from production masters, producing DVDs that'll be replicated in their 1000s. The client pretty well sets the technical standards in this country and as the work is being contracted out it can all get very political. I need to be 110% certain that the vision and audio is as pristine as it can be.
Bob.

>> Unless you monitor the audio during capture and noticed it sounds pretty bad or actually check the media properties you wouldn't know it'd gone wrong.

Yes, this is something I always does - checking the media properties. Them are (were) always fine in the cases I mentioned in the posting above.

Marco

Thanks for the info, the more we have thhe better. I'd do some more investigations myself if I wasn't so snowed under with work.

Deleted by User. Went to the wrong place.

Marco

I remember one case where audio properties start being very tricky but this in any application. Say I capture a dv tape via firewire. I usually only shot with 48 kHz. But sometimes the dv tapes are given to me from different people and sometimes here the tapes were prerecorded with 32 kHz.
Now when capturing my shootings it could happen that there was a bit of 32 kHz stuff recorded followed seamlessly by my actual shootings which were 48 kHz.
I don't remember what kind of problems it was - think it wasn't the frequency itself but something about correct synchronizing or a false field coupling.

Anyway, this is a case where trouble isn't far. When you have altering frequencies in input which might also appear if a soundcard or playback device maybe toggles something without you knowing it does.

Marco

Deleted by user. Went to the wrong place.

Sorry for the double post.

Marco

i just remembered ....
ok to begin with.. my gear..:

02R96V2
3 x layla24 (on TOS link)

and i have the mixer on int 48hz....and so the layla´s are on ext sync ..ok.

so at one time i was doing ADR and the mixer was set on int 44 hz BUT here´s tha catch..Vegas is set on recording at 48 hz,,, and guess what.. when i was done i realized tha what had done.. and changed tha mixer to int 48... and the offcource my recording sounded like Bugs Bunn... due to the SR offcource... so the mixer was the bug there,,, he was converting the SR so i had to resample all recordings.. but Vegas indicated that the rec was made in 48 hz but act it was at 44 hz,,,
Boooottttooom line.... i made the mistake Vegas did not...

even when i pv the sound when i capturing on the FW,, and the mixer is set to different SR, it sounds funky,,
like i said earlyer i dont use vegas for video i gave up on Pro tools,, and so i use only Vegas in audio PP,, done a few 5.1 full feature films on it,,, and it was pretty fun to work with and on..but mainly its tv
just trying to help..
check your ext sync and your int sync clocks...i´m betting 5 bux on it :)

BT

Farss, I don't suppose you've got a short sample DV .avi that shows this 32kHz problem that you could upload somewhere so I could have a look at it? Just a couple of seconds would be enough.

As I mentioned, I've not come across it myself but if I had a sample file to analyse I just might be able to get a clue as to what and where is going wrong.

Mark

I'll see what I can find. Problem is I'll have to capture just a few seconds else I'd have to render it out and that'd defeat the exercise.
Might take 24 hours, decks are all asleep or tied up capturing.
Bob.