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.

That's pretty serious. Could you report that here (or just email him on "satishATdebugmodeDOTcom"?

Can anyone else verify in V12/V13 with the latest Frameserver?

Earlier posts:

Sample Frequency / versions

Beta Test

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..

wwaag

This is a small problem.
The bigger is, that at the end of the framserved avi, there is a bug,
a click, i always have to trim it later! :(

Reproed in VP13.

OK, using the NEW auto FS >> HB workflow, I can FORCE 48. The resultant file is 48.

Grazie

I see this also. VP13 B373 and the latest frameserver. I frameserve to ffmpeg.

Most of my stuff is 44.1, so I just assumed that frameserver was taking whatever the project audio sample rate was. Apparently not.

I've emailed Satish about it. Hopefully it won't go to his spam folder as I've had discussions with him before.

That click at the end of the avi file that relaxvideo is reporting sounds like it could be related to this problem.

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.

Yes, exactly.
when i use procoder, i can trim it out.
But what about ripbot? I don't see here a trim option :(
So i always have to cut the last few seconds from the
created mp4 file with avidemux...

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.

relaxvideo,

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.

Project Default and Project Settings options are both presented in Vegas Pro 10. Project Setting option will present 48 kHz audio.

Vegas 11 only presents Project Default. Mediainfo reports the sample rate of the signpost file as 44.1 KHz.

Vegas 12 only presents Project Default. Mediainfo reports the sample rate of the signpost file as 44.1 KHz.

all test before the release for Vegas 13.

In the meantime, am I introducing some errors while in HandBrake FORCING 48?

Grazie

Sounds like it would be doing 48kHz > 44.1kHz > 48kHz. i.e. Not good

"Not good" - what would be detrimental?

G

2 x resampling = inevitable quality loss

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?

Grazie

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.