I was wondering if it was possible to read interrupted swipes accurately? and also is it possible for the software to be able to read more than one swipe at a time, and recognize the silent areas and cut them out? If you could customize the sofware to my needs i would be glad to pay something.
Regards
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To get multiple swipes to read you could play them back at real time and as long as your microphone is picking them up it should decode them. You might need something like virtual audio cable to achieve this. http://software.muzychenko.net/eng/vac.htm
Here are the problems with interrupted swipes and why it
really wont work with my software. Here are the steps required to
decode a magnetic stripe.
The first process just detects when a sample is high enough to not be
noise, basically noise is just ignored but when a swipe starts then
more processing is started.
Standard magnetic cards start with a bunch of 0's, this is to give the
decoding system an idea of how quickly a swipe is being swiped.
Meaning if you swipe a card at twice the speed you did initially, the
peaks will happen twice as often and the gaps will be half the length.
The samples will also be twice as high.
After the timing is determined the decoder has an idea of what a 0
looks like (the peaks are X samples apart normally), and also what a 1
looks like (there is an extra peak in the middle). Now it just decodes
binary until a start sentinel is found "11010" which designates that
data is actually following this sentinel. "Bytes" in this case can be
thought of as 5 binary digits, since 5 digits are decoded into a
letter.
From here on each 5 bytes is decoded into another letter until a stop
sentinel is found, which means that no more data is encoded on this
swipe. Traditionally a bunch of 0's are on the swipe after this point.
Now, going back to your question of why it cant do 10% at a time.
First if my software thinks the swipe has stopped and a new swipe has
started (i forget what the timeout is but you can check the source
code) then the whole process starts over. It looks for 0's, determines
the swipe speed then looks for a start sentinel. Two problems exist
here, it will assume that the binary it is decoding is 0's, but if you
are in the middle of a track it might not be, it could be in the
middle of 1's. Second the start sentinel wont exist twice on a card so
that will never be found and the byte offset cant be used to decode
the data into characters.
To prevent this you could "stitch" or cut these WAV files together so
that there isnt any downtime or muted audio between chunks of a swipe,
but you still have a major problem.
Unless you are doing this mechanically with a machine that you can
guarantee the card is being INSTANTLY brought up to speed and
INSTANTLY stopped then at the start and stop of the 10% swipe the
samples are going to be too low and ignored. Also the samples are
going to trail off, meaning during a decode i account for slight
variations in swipe speed. If you start at 1 foot per second, and
halfway through you speed up to 1.1 feet per second then this can be
detected because the samples should get higher and more importantly
the change WONT be instant. I'm decoding 44100 samples a second I
think so anything outside of an expensive robot can not modify their
swipe speed drastically in 1/44,100 of a second. As the swipe speed
increases or decreases it doesnt increase or decrease by more than 10%
a sample which makes the 1's and 0's still distinguishable.
Basically the only way reading 10% at a time was possible is if you do
it with a robot and cut the sections together, then my program could
read it.
The good news is if you really really need this my program is open
source and you can modify the way it decodes samples and get it to
work (maybe) if you know how to program, but I dont think it is really
possible.
I'd still like to look at a wave of a 10% swipe at a time and include
a full normal swipe and I might have a better suggestion.
The first thing i would look at is the peak value vs gaps between peaks, as you slow down a swipe the peaks get farther apart at a lower amplitude, and the inverse is true for speeding them up. You still have a problem of getting up to speed quick enough to not miss any bits because you'll hit the noise floor while you're starting to swipe the card again.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was wondering if it was possible to read interrupted swipes accurately? and also is it possible for the software to be able to read more than one swipe at a time, and recognize the silent areas and cut them out? If you could customize the sofware to my needs i would be glad to pay something.
Regards
To get multiple swipes to read you could play them back at real time and as long as your microphone is picking them up it should decode them. You might need something like virtual audio cable to achieve this.
http://software.muzychenko.net/eng/vac.htm
Here are the problems with interrupted swipes and why it
really wont work with my software. Here are the steps required to
decode a magnetic stripe.
The first process just detects when a sample is high enough to not be
noise, basically noise is just ignored but when a swipe starts then
more processing is started.
Standard magnetic cards start with a bunch of 0's, this is to give the
decoding system an idea of how quickly a swipe is being swiped.
Meaning if you swipe a card at twice the speed you did initially, the
peaks will happen twice as often and the gaps will be half the length.
The samples will also be twice as high.
After the timing is determined the decoder has an idea of what a 0
looks like (the peaks are X samples apart normally), and also what a 1
looks like (there is an extra peak in the middle). Now it just decodes
binary until a start sentinel is found "11010" which designates that
data is actually following this sentinel. "Bytes" in this case can be
thought of as 5 binary digits, since 5 digits are decoded into a
letter.
From here on each 5 bytes is decoded into another letter until a stop
sentinel is found, which means that no more data is encoded on this
swipe. Traditionally a bunch of 0's are on the swipe after this point.
Now, going back to your question of why it cant do 10% at a time.
First if my software thinks the swipe has stopped and a new swipe has
started (i forget what the timeout is but you can check the source
code) then the whole process starts over. It looks for 0's, determines
the swipe speed then looks for a start sentinel. Two problems exist
here, it will assume that the binary it is decoding is 0's, but if you
are in the middle of a track it might not be, it could be in the
middle of 1's. Second the start sentinel wont exist twice on a card so
that will never be found and the byte offset cant be used to decode
the data into characters.
To prevent this you could "stitch" or cut these WAV files together so
that there isnt any downtime or muted audio between chunks of a swipe,
but you still have a major problem.
Unless you are doing this mechanically with a machine that you can
guarantee the card is being INSTANTLY brought up to speed and
INSTANTLY stopped then at the start and stop of the 10% swipe the
samples are going to be too low and ignored. Also the samples are
going to trail off, meaning during a decode i account for slight
variations in swipe speed. If you start at 1 foot per second, and
halfway through you speed up to 1.1 feet per second then this can be
detected because the samples should get higher and more importantly
the change WONT be instant. I'm decoding 44100 samples a second I
think so anything outside of an expensive robot can not modify their
swipe speed drastically in 1/44,100 of a second. As the swipe speed
increases or decreases it doesnt increase or decrease by more than 10%
a sample which makes the 1's and 0's still distinguishable.
Basically the only way reading 10% at a time was possible is if you do
it with a robot and cut the sections together, then my program could
read it.
The good news is if you really really need this my program is open
source and you can modify the way it decodes samples and get it to
work (maybe) if you know how to program, but I dont think it is really
possible.
I'd still like to look at a wave of a 10% swipe at a time and include
a full normal swipe and I might have a better suggestion.
The first thing i would look at is the peak value vs gaps between peaks, as you slow down a swipe the peaks get farther apart at a lower amplitude, and the inverse is true for speeding them up. You still have a problem of getting up to speed quick enough to not miss any bits because you'll hit the noise floor while you're starting to swipe the card again.