jit.vcr audio oddness
Oct 20 2006 | 11:43 am
hi there, i'm using jit.vcr to record the output of a video/audio patch. the files i'm getting have audio that's shorter than the video. with a mov of 10mins 34seconds, when i spilt the video and audio i get an audio file of 10 mins 12 seconds.
- JeremyOct 20 2006 | 12:19 pmAre the audio and video out of sync, or is the audio simply truncated 22 seconds before the video? Or?jbAm 20.10.2006 um 13:43 schrieb owen lloyd:> > hi there, > i'm using jit.vcr to record the output of a video/audio patch. the > files i'm getting have audio that's shorter than the video. with a > mov of 10mins 34seconds, when i spilt the video and audio i get an > audio file of 10 mins 12 seconds. > > any ideas? > > thanks > owen
- owen lloydOct 20 2006 | 12:27 pmout of sync. all the sounds are there, it's just slightly time compressed so it gets worse over the 10 mins. either that or the video is too long... odd.
- firstname.lastname@example.orgOct 20 2006 | 6:44 pmhi,I actually got the same problem, couldn't get it to work, was in a rush and ended up recording the old way.With jit.vcr I always was ending with video that was longuer than the sound (the sound was the correct lenght but the video was time stretched). I wanted to investigate a little further if it was not a user error before writing to the list but never got to it...It was with jitter 1.6/ OS X.4.7 macbook pro (but I believe it also happened on a G5)Denis
- owen lloydOct 26 2006 | 5:31 pmit's a weird one, i'm on os10.4.7, g4 powerbook by the way.
- email@example.comOct 26 2006 | 6:17 pmI am wondering if it has to do with frame rate issues with the video recording. As opposed to jit.qt.record, jit.vcr is necessarily always in realtime mode, but I would imagine that irregularities in the recording frame rate could cause some problems over time. Being a real novice with dig.vid. issues, I don't really know, but it is my assumption about it at this point.Tim
- owen lloydNov 01 2006 | 9:30 amhi tim, i had investigated this issue but the numbers suggested it wasn't an problem. activity monitor showed total cpu use was around 40% and i was going from one read disc to a different record disc using 320x240 sized files. no great stress there. i also recorded deaf and blind, as it were, with no monitoring of the visuals or audio to add to the load. still weird stretchy video...