I'm using an older version of Frameserver in Vegas Pro 10.0e. It serves audio at the same frequency as the project settings (I verified 48kHz and 44.1kHz by opening the signpost file in Mediainfo). Is the current version behaving differently?
wrote on 9/3/2014, 11:13 PM
It seems to be stuck at 44.1 regardless of project or file settings.
I rendered it out and it is indeed 44.1. This is the latest version for Vegas 12.
Yes. Same here. I've made this point several times on the Debugmode forum and here as well. Seems there is not a big concern about the downsampling and then upsampling. I always render out the audio separately and then remux. Too bad, especially now there is a direct way to frameserve to Handbrake..
Same here. It is always exactly one second that will be repeated at the end and within the original duration of a clip. So in the Vegas2HandBrake workflow it is advised you'd add 1 second buffer at the end of a Vegas Pro project which then will be automatically trimmed by AviSynth.
Interesting. I do not get the 1 second problem at the end. I am frameserving the audio. I am not using the option to put the audio in the AVI signpost file.
Initially I used AviSynth 2.5.8 but the audio frame serve did not work and I had to put the audio in the signpost file. So I tried AviSynth+ and the audio frameserve works fine. I am frameserving to the ffmpeg console app and my audio is being encoded to mp3 format.
AviSynth+ is someone who recently took up developing and extending AviSynth since that was last updated in 2010.
wrote on 9/4/2014, 10:11 AM
I don't think it is a small problem. I think it is a big problem. I don't want my audio to be upand down sampled.
The click problem could be related or could be a different issue entirely.
I agree. It is big problem. Vegas will happily conform the video and audio to the video size, video frame rate, and audio sample size and sample rate that an encoder specifies it wants. The template params.
Frameserver accepts whatever video size and frame rate from Vegas. It should do the same for audio. Of course Video for Windows may have some limitations to the boundaries since for frameserver were are using VfW.
Satish has told me that he's asked his contact at SCS if there has been any recent change in the Vegas interfaces that frameserver doesn't know about.
It sounds like he might be thinking they are problems that have arisen since he finished coding 2.15. But it's sounding to me that the problems might have been there and not picked up. Therefore it might be useful here to list exactly which combinations of versions of Vegas Pro (V11/V12/V13) and Frameserver (2.14/2.15) exhibit these problems.
Sure, I understood that this may or could be the result, but I'd like to see (hear) this. Are there any scientific CHARTS to view? For this 48>44.1>48 route. Would the sampling "affect" the video - ie lower sampling force some Media Length or Sync issues on the way back up to 48?
I've never seen any sync issues doing stuff like that. I think it would be unlikely.
To test the quality loss you could make some test audio, put it on a really tall track and study the waveform before and after the resampling. The other thing you could try is a massively exaggerrated number of iterations of the same resampling. e.g. take it to 44.1 and back to 48 something like 30 times and see how many cycles it takes before you can actually hear the degradation. i.e. Like how people on here have tested video codecs in the past.
wrote on 9/5/2014, 7:00 AM
Same as John Dennis.
I don't know how much damage is going on since we don't know who is actually doing the downsampling. What quality of downsampler is being used.