Comments

Nick Hope wrote on 9/3/2014, 10:22 PM
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?
Former users 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.
Nick Hope wrote on 9/3/2014, 11:41 PM
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?
wwaag wrote on 9/3/2014, 11:46 PM
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
relaxvideo wrote on 9/4/2014, 12:39 AM
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! :(
Grazie wrote on 9/4/2014, 1:18 AM
Reproed in VP13.

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

Grazie

NormanPCN wrote on 9/4/2014, 1:24 AM
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.
Nick Hope wrote on 9/4/2014, 4:52 AM
I've emailed Satish about it. Hopefully it won't go to his spam folder as I've had discussions with him before.
Nick Hope wrote on 9/4/2014, 4:57 AM
That click at the end of the avi file that relaxvideo is reporting sounds like it could be related to this problem.
Marco. wrote on 9/4/2014, 5:02 AM
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.
relaxvideo wrote on 9/4/2014, 5:04 AM
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...
NormanPCN wrote on 9/4/2014, 10:01 AM
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.
Former users wrote on 9/4/2014, 10:11 AM
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.
NormanPCN wrote on 9/4/2014, 10:27 AM
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.
Nick Hope wrote on 9/4/2014, 11:17 PM
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.
john_dennis wrote on 9/5/2014, 12:12 AM


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.
Grazie wrote on 9/5/2014, 1:03 AM
In the meantime, am I introducing some errors while in HandBrake FORCING 48?

Grazie

Nick Hope wrote on 9/5/2014, 1:41 AM
Sounds like it would be doing 48kHz > 44.1kHz > 48kHz. i.e. Not good
Grazie wrote on 9/5/2014, 2:11 AM
"Not good" - what would be detrimental?

G

Nick Hope wrote on 9/5/2014, 2:34 AM
2 x resampling = inevitable quality loss
Grazie wrote on 9/5/2014, 2:39 AM
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

Nick Hope wrote on 9/5/2014, 6:43 AM
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.
Former users 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.