What feature from the "new" FS vinyls is missing on SSL?

The 3 types are - Thick, Thin, and "New". I got the new ones when I bought FS (what a waste of money!). They are basically like the thin ones, but with a special timecode in the lead in so FS can tell when the track is about to start, and the display shows you moving up to the start. Not sure how useful it actually was though, I haven't missed it.

Sounds like the "New" FS ones are like the standard Scratch LIVE control records, which have 3 seconds of control signal in the lead-in.

... lol i dont see why this is new... i rememeber this was present in FS 1.0

Nope, this "feature" with lead in graphics has been introduced in FS 1.5.x.

Hey has anyone tried using FS vinyl with Serato. Does it work?

Won't work. Two completely different systems - one is called timecode and the other is called 'not timecode' or noisemap.

We call it a "control signal" :D

lol :D

Actually, ours is called a maximal-length pseudo random bit sequence, it is generated using a linear feedback shift register. See why we haven't really been throwing the name around? That's why I came up with the name NoiseMap - it is pretty close to describing the code concisely.

We came up with this idea, and in our opinion it is vastly superior to timecode. The basic reason is that it has way more redundancy - each error in the sequence has a much lower impact than it would in a timecode. I can go into the details if anyone is interested.

As for whether the FS record will work - to an extent they probably do. We use a quarter-cycle phase quadrature sine wave to track direction and speed, and FS must use the same - I mean it's obvious right? What else would you use? The difference would be in the frequency and possible the direction. This means that although absolute position detection could never work (because timecode =/= noisemap) relative mode should work, but probably at the wrong speed and maybe in reverse.

So the idea is basically, get a code which has as much entropy as possible, or in an n-dimensial vector space let them have as much distance as possible...?

If you have more details, dont hesitate, I like those maths talkings :)


Why is it obviuos that you should use a quartert-cylce phase quadrature sine? And what is so special about? What is it anyway? I thought (from the analysis dj ville e has done some time ago) that its a simple 5kHz sine wave?

What is the reason that you have splited the timecode in a left-side part and right side part? It should theoretically work with one mono signal, or?

Sort of. The idea is to get a sequence of bits in which you can find your position uniquely in the shortest number of bits, without having to synchronise. The problem with a timecode is that you have to know where each code ends and the next begins. With the noisemap you don't have that problem because the code is continuous. At any position in our noisemap, you only have to read 20 consecutive bits to find your position, with a timecode you have to wait until you find the start of the next code, and then you have to read bits until you have an entire code. If you want to make sure you don't make a mistake, then with timecode you have to read another entire code sequence, or several. With our noise map, each bit that you read adds more confidence to the reliability of the position.



It is just a simple sine wave, at 1kHz. I just meant that one channel is one quarter cycle ahead of the other, which is why you get a circle when you plot x vs y. It's special because when you play it backwards, the sense of which channel is in the lead changes. Or, think geometrically, the point in the circle rotates in the opposite direction. It is the same technology that has been used for decades for this type of problem, the ball mouse is a perfect example.


<sigh> At the risk of sounding like a broken record (LOL!), we don't use a timecode. Furthermore, we don't split it into the left and right channel. There is one bit per cycle which is evenly spread across both channels. If you only had a mono signal, you could stil decode the noisemap, but you would not have instantaneous direction information, that is what the quadrature is for.

holy crap. I don't think I've ever heard many of those words. I'm scared

:-D

s

yea...the knowledge in this place gives me a warm and fuzzy feeling inside...lol

AJ, can you maybe explain why it gives more redundancy?

Wow, talk about digging up an old thread.

Basically the redundancy comes from the fact that a noisemap is a bit sequence where every code completely overlaps the previous code except for one bit. Like this...

0001101010101001101101100010101 ... code 1
0001101010101001101101100010101 ... code 2
0001101010101001101101100010101 ... code 3

where I have made bold each code in the sequence one at a time to show how they completely overlap. Compare this to timecode...

0000000010010110 0000000010010111 0000000010011000
0000000010010110 0000000010010111 0000000010011000
0000000010010110 0000000010010111 0000000010011000

So imagine if one of the bits in the sequence had an error, in a timecode it would screw up a whole code sequence, until you hit the beginning of the next whole code but in the noise map the bit directly after the error bit would be the start of a new code every time. Basically every bit in the whole noise map is the start of a new code so you can drop in anywhere and start decoding.

Does that make sense? There is also more redundancy in the way that we encode the actual bits, because we only encode one bit per cycle, whereas the FS timecode attempts to cram as many bits as possible into a small time segment.

Okay, as far as I understand this affects the latency in the way that a correct absolute timeposition can be read faster... but I wouldnt call this a redundandy feature. Or?


Doesnt this make work against the attempt to read faster an correct absolute position code (with the help of the shifted/cyclic timecode)?

Does this mean...
1kHz carrier = 2000 half cycles/second, so you need 20 consecutive bits, then you need 20 half cycles, equals to 10 full cycles which gives 100 absolute position codes each second, which means it takes 10ms to read the controlsignal properly?

From what I can see with the FS2 cds I have here they use one bit for each half cycle, if its a "1" the amplitude is three times higher than with a "0". I can see smaller and bigger amplitudes in SSLs control signal, but the difference is very little. Whats the reason why this difference is small/wouldnt it better to have bigger differences like in FS2 to make sure a "0" is can be distinguished from a "1"?

Theoretically this sounds like a good idea, but in practise it cause harmonic distortion because you can't follow the most important signal closely enough. The most important signal is the carrier. In usual timecode applications, the carrier signal is not important at all, but when you are scratching or even just playing audio the purity of the carrier signal is extremely important.

In this application, the position is secondary to the carrier because the carrier is measured a hundred times more often than the position code.

BTW, I have measured the SSL latency, and with a USB buffer size I get 8ms (about 354 samples) until a signal comes in, and until a proper signal comes in it takes 10ms (about 443 samples).

With FS2 and the lowest latency setting I still get 22ms (about 955 samples, first signal) and 24ms (about 1097 samples, proper signal) and that is with the lowest latency setting! (latency with highest setting 108ms!)

So in terms of latency FS2 has not improved. Sad.

Nik .. with that said I wonder how its doing backspins and the other stuff you mentioned in a previous post better than SSL ... voodoo ?

Refer to this thread for Nik's finds on FS2 ..

www.scratchlive.net

Is it?

Ahh - checked niks thread...interesting.....

FS2 didn't work for shit on my laptop, pops and clicks and stutters being understatement of the year - I use the same laptop for SSL and SSL sounds rich, full, detailed and I never notice any pops clicks or anything - YAYY!

I mix into regular vinyl too and the sound quality is not really different - regular vinyl 12"s are just a lot louder. (subjectively at least and on the meters - I don't want to argue tech stuff and mixer line channels being crap and all that)

Sound is awesome.

s42000, misunderstanding I guess, you should read my post thoroughly:



Those (and other things) mentioned in the post have nothing to do with latency. Latency is a different subject, and I havent commented on it (except when I said "scratches sound great", they do sound quality wise).

Still questions?

Well, mucho kudos for you gettin FS to work on your system and I'm glad you happy with it!

I for one never really had to much trouble with FS1.5, aside from the arifacts (poping, garbled noises every so often). What royally pissed me off is their support... and they still haven't done a thing for that.

I'll keep SSL, specially since it's working perfectly for me these days. I only wish a lot of other people had the track record wtih FS2 like you did nik, some of those thread scare the crap outta me over at the forums....and I don't even own FS!

Absolutely. My problem with FS1 was never solved neither by stanton nor my NI, allthough it has been proven that the h/w was faulty! A big **** off goes into that direction!! The german distributor (NI is based in Germany as well!!) helped me, a sad story.

Wow you are all gonna love me bringing this back out of the graveyard of time but I'm stumped on this lfsr stuff.

From what I understand from lfsr's any position in the sequence depends on three things: the taps used, the previous bit sequence and the seed with which the code was created.

How is it possible then to get position data out of this?? You'd need to use a huge lookup table to find yourself within 2^20 locations in the sequence (assuming a maximal tap sequence was used and there are 20 bits in a hunk of data)

How is it possible to get such low latency if you use a lookup table??

thanks for the info and sorry again about dragging this up. I like thinking about this kind of stuff.

~jamis

No need to do a linear search, binary tree lookup takes exactly 20 steps. You could use an intelligent data structure which uses 20 different binary trees, or link them in a intelligent, efficient wayy.

I dont understand what you mean with "taps used" and "seed". What do you mean?

The Rane Scratch code was created using a 20 bit Linear Function Shift Register. The basics of LFSR generation can be learned here (be careful, there is a mistake in the animation...):
en.wikipedia.org

The code uses high and low pulses to represent a 1 or a 0 respectively. One bit is represented in the wave form as a peak and a valley combined - one cycle. The left channel and the right channel have the exact same wave form on them except for a 90 degree phase shift. This shift can be used to figure out which direction the needle is moving in the groove.

The seed of the Rane Scratch code is, in a way, the very first 20 bits on the record... well if you take the needle and try to find the very beginning of the record by back cueing slowly you'll probably find that the needle runs off the edge of the record before the code stops.

By downloading a recording of the Scratch code cd that can be found here:
www.rane.com

it's possible to get a clean wave form of the first 20 bits in in the sequence. This is, for all reasonable uses, is the seed.

There are algorithms that can take a size-able chunk of code created using an LFSR and then give back the bit size and where the taps are taken from in the code. Using this information it is possible to create an exact copy of Ranes code. I won't post the taps here I'm sure Serato/Rane wouldn't like that too much and it took me some time to figure it out but really it was just a fun test to see how exactly LFSR's work.

After thinking about it more last night I figured that a lookup table wouldn't be all that slow. It's possible to step through the entire LFSR code in under a second (that's 2^20 bits). I wish there was a way to calculate the position in an LFSR using the seed and the taps and the distance out from the seed but a lookup table does seem rather manageable.

Rane really does have their act together. Using and LFSR takes a large number of noise checking and data accuracy technics from the communications field and applies them to better tracking and position error checking.

What does somewhat disappoint me is that they don't really need to have an external box for all of this. It should be possible to plug two turntables into two sound card inputs and then have the audio go to the mixer from the sound card outputs. No extra box or cables in the dj booth. It'd be just the same amount of cables as having a computer and two turntables hooked up to the mixer.

By including the "magic box", Stanton/NI, Serato/Rane and all of the other (about 4) companies that create control vinyl can up the price of the setup well over $200. If were possible to use these magic boxes in the way they were originally designed (a 4x4 usb audio interface.... two stereo inputs two stereo outputs) their price may be a *bit* more reasonable... but in my opinion, after learning what I have about Stanton/NI and Serato/Rane, I must say it's kind of cagey to charge a list price of $800 for either option with the audio interface combined with the price of the software.

Along with this, It should be extremely easy to allow either box to work with either software... but they're competitors so the options available to the public are diminished even more.


Thanks for the information! It was a fun task to figure it all out and Rane/Serato, very good thinking on the choice of code. It is really much more intelligent then the others out there.

p.s. I haven't figured out how the scroll section on the record works yet... I haven't looked at it yet...

Thanks for the wiki link, now I know what you mean with the terms.


One second for one lookup is by far not sufficient, remember you have like 1000 a second. But as said before, use a binary tree to represent 2^20 combinationas, use 20 different trees (or a data structure which uses pointers to pack all 20 trees into one) and you can find out the proper position within 20 edge traversals, which should be more than sufficient.



You have to keep in mind that with the box you charge (thats the only way to make money, if you give away the software *and* all updates for free!) you have to pay *all* costs, R&D, marketing etc. Remember... they are constantly updating the software, and they havent charged a single cent from the users which bought the box 3 years ago. So that may explain the price. Also Rane is known to give superiour customer service. This has to be funded - by sales. Thats how it goes.


Yep.



I think this is just a part of the 'timecode' which is used for scrolling. So the original maximum control-signal sequence goes about 17:28 minutes, you use the first 15 minutes for 'normal' control and map the remaining 2 1/2 minutes to scroll selection.

Since the time it takes to count up through 2^20 is less then one second, I'm sure it wouldn't be any issue at all to do a lookup 20 deep in a tree.

So, I agree, it is doable! :D



ah true... and I'm sure a bunch of people would rather have a usb box to plug into their laptop instead of trying to get a multiple input multiple output sound device on their own.



Maybe now that the whole final scratch thing is falling apart with regards to support maybe rane will make some hack that lets users use final scratch vinyl as well as rane...... even if the final scratch code isn't as good...




That's what I was guessing and also why I haven't bothered looking at it yet.

thanks for the discussion!

I am not talking about a linear search, don't know if that is clear or not.

Wow Rane! Nice work with the LFSR idea.

So for those of you wondering why the latency is so much less with this LFSR design vs the lookup table design from FS here is my modest attempt at a simple explanation:

LFSR:
You need a minimum of 20 bits that match an LFSR code(the output of the LFSR changes to let you know you are in sync), of course it doesn't always happen with the first 20 bits because you might have some bit errors, so it won't sync until you get at least 20-bits in a row without errors. Once they sync, they still have to do error checking to account for single bit errors and such, basically this is the same thing as CRC. You might be familiar with that term from TCP/IP. So most of the time, clean record, clean needle, clean power, 2kbits each second, it takes about 1/100th of a second to sync, or 10ms.

Lookup table:
You have to wait for several whole timecodes to be read in by the SW to make sure they are in the right order and to find your location in the table. The time codes stream in serially, so you have to figure out where the boundaries are by reading in several codes and trying to match that sequence of codes to somewhere in your table. Two slow things, 1) reading in a few codes 2) hashing through your table. I don't know how they did their timecode design or how many bits per timecode, so I can't say exactly what the expected delay should be, but it will behave much worse with bit errors than lfsr. Meaning you need to have a better needle, cleaner Vinyl, etc.


Hopefully that gives you a bit more layman's explanation to why LFSR is twice as fast, and stemming from that thought, why Rane/Serato is a cut above...

1kbits ... 20ms.

Oh, and BTW, this was Serato's idea, not Rane's ;)

wait, i thought a half cycle was a bit....

to clarify, I said

2kbits/sec = 20 bits in 1/100th of a second = 10 ms

Huh, that seems confusing to me, since you have a positive half and a negative half to a sine wave, why wouldn't they take advantage of that?

*smiles*

*smiles again*

Every time I have a headache I come to this post. Calms the nerves :)

Carry On!

Wow, lotsa knowledge throwin down up in here

[Stares closely @ the groove of the control vinyl]

+1


And there was me just thinking it was a 15 minute long "Beeeeeeep"

Talk about bringing a thread back from the dead. An oldie but a goodie. Lots of knowledge and info here.

g33kt4Lk

Watchwww.youtube.com

Quoting AJ in this thread, back in 2005

I apologize if I missed it, but is there a reason that the code can't be extended to, say, 60 minutes?