On Thu, Feb 18, 2010 at 7:15 AM, Owen Williams <[email protected]> wrote: >> Good question. The answer is that if you don't keep the timecode and >> playback time in sync, then it becomes impossible to tell the >> difference between the timecode cutting out and a needle drop. The >> timecode might cut out if you hit a piece of dust on the record, or >> maybe you get some epic bass rumble in your turntable at one point in >> a song. To the software, this looks exactly the same as a needle drop >> - You lose the timecode, and then it magically reappears. So to decide >> whether or not there should be a seek, you have to look at the current >> playback time AND the newly picked up timecode. If the timecode is >> significantly different from the playback time, then it's safe to >> assume this is a needle drop. If the timecode matches the playback >> time more or less, then it's probably not a needle drop. > > What I do is, for every loop, remember the drift amount (difference > between file position and vinyl position). Then, when timecode is lost, > we still have pitch so we know how the record is moving and the file > position keeps getting updated. So I just calculate an estimated vinyl > position by taking the new fileposition and adding the drift amount > back. Then when timecode is recovered, we have a good guess as to how > much the needle really moved. For a piece of dust, the new drift is > going to negligible, so mixxx won't resync. Even with a multi-second > pullback, the estimated position has been good enough. >
I like this approach, and it never occurred to me. What's the advantage of going this route instead of constantly applying a drift adjustment to the pitch? > What should happen if the record gets stuck and jumps 5-10 seconds at a > time? Should that be detected, or should the track just skip? (I don't > know how serato handles that). The only way I can think of telling the > difference between a needle drop and a stuck record is if there's a > regular period of stuck-ness. Mixxx could automatically tell the record > to keep playing at the previous rate, and the dj could clean off the > needle and the record while the track is going. Then when they do a > needle drop, mixxx would be set to relative mode because the needle drop > isn't going to be anywhere near the skip position. (And still, you're > going to get at least one skip before it figures it out, and you'd need > all sorts of UI elements to announce that your record is skipping.) > These are all good, open questions that I don't have an answer to, but I'm excited to see that you're thinking about all these cool possibilities. If you try to code something like that, I'd use the "needle skip prevention" flag that we already have and change it to something more general like "needle skip and broken record protection". You definitely have a really cool idea. :) Thanks! Albert ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Mixxx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mixxx-devel
