What is F2F encoding?
As you know, when recording information on the magnetic stripe of a plastic card, the so-called F2F coding is used - "Frequency - 2 Frequency", loosely translated "Frequency, doubled frequency", which is a kind of FM coding - "Frequency Modulation" ... In FM there is a signal with constant amplitude (carrier), but changing (modulated) in frequency.
I will try to explain "on the fingers" how information is recorded on the magnetic stripe, and what is F2F modulation.
I will say right away that due to the advanced age of technology, all information on the magnetic stripe is recorded in the "sound" band (20Hz - 20,000 Hz). Naturally, the frequency of the signal on the magnetic stripe will change linearly depending on the speed of the plastic card, but the specification of the standard states that this speed should be from 10 cm to 2 meters per second. At a conduction speed of less than 10 cm / s, the EMF arising on the magnetic head of the reader will be critically low, and at a speed of more than 2 m / s, the signal frequency will go out of range (20,000 Hz, which is 20 kHz). From this it follows that to work with information on a magnetic tape of a plastic card, we will have enough hardware and software for working with sound. A small lyrical digression:
What is F2F modulation? Imagine that at a certain constant speed of the magnetic tape, we have a carrier at, say, 2000 Hz. Let's take it as logical 0. In this case, logical 1 will be equal to twice the frequency of logical 0, which is 4000 Hz. But, since data must be transmitted at a constant speed at a constant speed of the magnetic tape, then log. 1, encoded at twice the frequency, must also have a doubled period. It follows from this that the log. 0 represents a half-cycle, and log. 1 - full period at doubled frequency log. 0.
For clarity, I will give two graphs:
The first graph shows that in a unit of time, the carrier has completed a full period, and in the second graph, it can be seen that in the same unit of time, the carrier has completed only a half period (and the frequency, accordingly, has halved).
Now let's take a graph of a short duration and divide it into equal time intervals (ticks) equal to the duration of a logical zero.
It is absolutely not difficult to determine the information encoded on the chart (11011001011000). Now the question arises: how to actually determine this very duration of a logical zero (clock)? For this purpose, at the beginning and at the end of the magnetic tape there are 10-15 "input" and "output" zeros, which do not carry any information, but only report the duration of the log. 0 and, accordingly, used by the hardware to synchronize the cycle. These lead-in and lead-out zeros are placed on both sides of the magnetic tape, since the tape can be read in both directions, and it must be synchronized before reading the information.
Accordingly, it becomes clear how hardware F2F decoders installed in plastic card readers work:
1) As soon as the decoder “saw” that zeros “went”, it determines the frequency of these logs. 0 (carrier frequency), sets the duration of one "cycle" (one bit of information is transmitted per cycle) and gives a Card Present signal.
2) If the decoder detects that a full period has occurred in one clock cycle, it sends a log. 1, and starts decoding in a similar way the entire track (for one clock - half cycle - log 0, for one clock - full period - log 1).
3) As soon as the decoder loses the carrier, it gives a Card Not Present signal and that's it.
We now understand how an industrial hardware decoder works. We draw conclusions:
1) For synchronization, it necessarily needs input logical zeros, i.e. after stopping while reading the magnetic strip and resuming movement, the decoder will no longer be able to synchronize and will not work. In other words: all information recorded on a magnetic tape after stopping it will be lost. For example, if you stop holding a plastic card in the middle of the magnetic strip, the decoder will give out only half of the information.
2) Changing the speed of the card by at least 25% - and the decoder gets out of sync and sends us to hell, i.e. Card Not Present signal or complete nonsense in the form of incorrectly defined logs. 0 and log. 1.
In everyday circulation, plastic cards are always passed evenly and without interruption, so that the developers and manufacturers of plastic card readers never faced the question “How to read cards with a stop and change in the speed of the card?”. And technically, it is extremely difficult to do it, almost impossible, since at the moment of stopping several bits of information are lost, and there is nowhere to recover them.
Now let's assume the following situation: we have an industrial decoder and the card is drawn with a stop, first in one direction, then in the other direction, also with a stop. (But attention! The change in the speed of conducting should not change by more than 25%, otherwise it will turn out to be complete nonsense.) Accordingly, during the movement "there" we will read the conditionally "right" part of the map, and "back" - the "left" part cards, and we "glue" these two parts, we get a full track. Yes, sometimes it happens, but only sometimes. I explain:
Let's say at the first movement "there" we will have a stop at 50% of the map, respectively. somewhere around 45% will be read, and the remaining 5% will be lost (or get the wrong bits) due to desynchronization during the stop. When moving "back", we will also stop at the same place at 50% of the card, and again only 45% will be read. In total, we will get 45% of the beginning and 45% of the end of the track, but this is not 100%, and, accordingly, the track will not work right for us.
Hence the conclusion: "gluing" from two parts, when using a hardware decoder, is possible only with an even speed of conduction and with an "overlap" of the "input" and "output" movements (for example, at the entrance we get 55% and at the exit 52%), which turns out rarely.
But how, then, to read the "broken" tracks? First, let's forget about the hardware decoders and take a look at the audio recording of the magnetic stripe. We absolutely do not need to synchronize on the input zeros, we, and so straining our logic, purely visually can determine where we have a log. 0 and where is the log. 1. And manually recording 0 and 1, restoring what was lost during the stop from the second movement, we will be able to restore the same "broken" track without problems and errors. But taking into account the order of 200 bits for only Track 2 (and in Track 1 there are generally about 560 of them due to the three times higher recording density), such an occupation is extremely dreary and can drive you crazy. How can we more or less automate this process?
Firstly, we do not need to have an audio recording schedule in front of our eyes, and we only need to know how much time has passed from one peak of a half-period to another peak. Let's go back to our log graph. 0 and log. 1 and conditionally divide one bar into 40 more bars (the 20th bar is highlighted in blue).
From this graph we can see that for the half-period log. 1, it took us 20 cycles and another 20 cycles for the second half-cycle, and for the half-cycle log. 0 it took 40 cycles, i.e. twice more than half-period log.1.
Let's say we have the following "timings" (that's how I conditionally called the number of bars spent on one half-period): 91, 45, 44, 91, 88, 46, 44, 44, 42, 85, 41, 43, 38, 39 , 38, 39, 39, 41, 77, 78, 74, 40, 39 the amount of time spent on one second half-cycle. The volume of one tact is required to know only flax will not work. ... Next, you will find out where it all comes from. Let's try to decode them (remember, log. 0 - half-period, log. 1 - full period (two half-periods at the doubled frequency of half-period log. 0):
91 - it's hard to say, because we don't know the duration of zero yet, but as it turns out in further, this is log.0
45 - half of the duration of the previous timing, this is definitely log.1
44 - and this is the second half-period of the previous log.1
91 - twice as long as the previous timing, log.0
88 - log. 0
46 - log. 1
44 - the second half-period
44 - log. 1
42 - the second half-period
85 - log. 0
41 - log. 1
43 - the second half-period
38 - log. 1
39 - the second half-period
38 - log. 1
39 - the second half-period
39 - log. 1
41 - the second half-period
77 - log. 0
78 - log. 0
74 - log. 0
40 - log. 1
39 - the second half-period
So we get 010011011110001. These timings were "removed" from the real audio recording of the magnetic strip of the plastic card. The audio recording was made with a sampling rate of 44100 Hz, I think you can find such a sampling rate on google.
Accordingly, one clock cycle is equal to 1/44100 of a second, and if we have an average log. 0 is 83 cycles (discrete), then the audio frequency log. 0 in this case, 44100/83 = 531 Hz, and log. 1 respectively 531 * 2 = 1062 Hz. 531 Hz and 1062 Hz are between 20 Hz and 20,000 Hz, which means that the card was drawn at normal speed, within the standard. By the way, in accordance with the Kotelnikov theorem, at a sampling rate of 44100 Hz, the maximum frequency that we can record is 22050 Hz, i.e. the sampling rate of 44100 Hz (the standard sampling rate of audio data on Audio CD) is quite enough for us to digitize information from the magnetic tape of plastic cards.
So, now we know that we can get data bits from the audio recording by calculating the timings between the peaks of the half-waves, and for this we absolutely do not need leading zeros for synchronization, since we, so to speak, "synchronize" every time with each new half-wave. And even if the card is VERY abruptly stopped, it will not stop absolutely instantly, but will stop with some negative acceleration, i.e. duration (number of ticks) of two adjacent half-waves log. 0 will not change by more than 25%, so we can decode this information without any problems.
Decoding of zeros and ones.
I will say right away that in the future there will be a description of decoding only the second track. The first track differs from the second only by a higher recording density and the use of 6 + 1 bits per character.
So, on the second track, we can only have 39 characters + the LRC check character. There are 4 character bits per character + 1 PCB bit (Parity Check Bit), for a total of 5 bits.
The picture above shows the direction of the data. Those. data is written right-to-left.
The data on the second track according to the ISO standard is as follows:
1) Symbol ";", means the beginning of the track
2) 16 numeric characters
3) Symbol "="
4) 20 numeric characters
5) Symbol "?", Means the end of the track
6) LRC check symbol
For example
:; 1234567890123456 = 12345678901234567890? * (* Is LRC)
Bit value table:
If the card is drawn in reverse order (from left to right), then in this table the bits are placed in reverse order: Bit No. 5, Bit # 4 ... Bit # 1.
Now I will explain what a parity bit is: let's take the character "3", it is written as 1100, it contains 2 ones and 2 zeros, and 2 is an even number, respectively, in the parity bit we have 1. Take the character "7" , it is written as 1110, it has 3 ones and 1 zero, and 3 and 1 are odd numbers, therefore in the parity bit we have 0. The parity bit can indicate to us that one of the four bits of a character or a parity bit read incorrectly. For example: if we have 01100, then you can immediately see that 0110 is even, and the parity bit is 0, respectively, one of the bits in this symbol is decoded with an error.
Now let's take a "live" example of timings:
153 - 0
145 - 0
139 - 0
125 - 0
121 - 0
118 - 0
115 - 0
116 - 0
110 - 0
107 - 0
104 - 0
101 - 0
99 - 0
98 - 0
46 - 1
49
47 - 1
47
91 - 0
45 - 1
44
91 - 0
88 - 0
46 - 1
44
44 - 1
42
85 - 0
41 - 1
43
38 - 1
39
38 - 1
39
39 - 1
41
77 - 0
78 - 0
74 - 0
40 - 1
39
37 - 1
38
77 - 0
37 - 1
39
So, we got the following: 0000000000000011010011011110001101.
As we can see, first we have leading zeros, we discard them, and the remaining bits are divided into groups of five bits:
1 1 0 1 0 - ";", the character of the beginning of the second track
0 1 1 0 1 - "6"
1 1 1 0 0 - "7"
0 1 1 0 1 - "6"
I think that everything is very clear and understandable here.
Now I will explain what is behind this cryptic Longitudinal Redundancy Check symbol that runs at the end of the track. Having divided the bits into groups of five in the example above, we consider how many bits No. 1 we have in these four symbols - two bits (even), bits No. 2 - 4 (even), bits No. 3 - 3 (odd), bits No. 4 - 1 (odd), bits # 5 (parity) - 2 (even). If only these four characters were recorded in the second track, then after them, the LRC check bit would follow. It also contains five bits of information, and bit # 5 in the case of the LRC symbol NOT (!) Performs the parity check function. The LRC symbol contains such bits that the total number of all bits of the given number (for example, bits # 1) becomes even. In our example, we see the following:
Bit # 1 - even
Bit # 2 - even
Bit # 3 - odd
Bit # 4 - odd
Bit # 5 - even
Therefore, our LRC symbol will be 00110:
Bit # 1 - 2 + 0 = 2 - even
Bit # 2 - 4 + 0 = 4 - even
Bit # 3 - 3 + 1 = 4 - even
Bit number 4 - 1 + 1 = 2 - even
Bit number 5 - 2 + 0 = 2 - even
I will pay attention once again: LRC symbol in this case looks like 00110, and the number of ones and zeros in the first four bits are even, but bit # 5 is 0. Let me remind you again that in the LRC symbol the fifth bit is not the parity bit of this symbol.
So, if we have any bit from the whole track (but unfortunately, only one bit) is read (or decoded) with an error - by the parity bits, we will determine in which symbol we have an error, and by the LRC symbol we will determine and we will correct the error already inside the erroneous symbol.
Convert WAV to txt
To work with WAV files, we use the program.
By the type of this program, there are also Sound Forge and WaveLab.
So, let's assume that we recorded the second track on a dictaphone with the following parameters (set by default):
Sampling frequency: 22050 Hz
Channels: 1 (Mono)
Bit depth: 16 Bit
Open the wav file in Cool Edit and see the following picture.
In the lower right corner the parameters of our record, which I wrote about above, are indicated.
We see two areas. Apparently (and this will be confirmed later), the first is the "input" (normal bit sequence) card pass, the second "output" (reverse bit sequence) card pass. With a certain skill, the direction of passage of the map can be determined with ease. We also see that the "input" pass was at 48 seconds of recording, and the "output" at 53 seconds. Knowing the start time of the recording, we will know for sure the time of passage of the card.
We see that we have "Exit" with one stop and we will take it as the main one, and we will use the "Entrance" to recover the lost data of the "Exit".
The first thing we do is select the entire "output" and copy it.
Then click in Cool Edit: File - New ...
Set the following parameters for the new file:
44100 Hz, Mono, 8 Bit
Insert into a new file "exit", select the silence at the beginning, end and middle (stop) of the file and delete them with the Delete key.
It turns out the following: We check that the file duration does not exceed 1.4 seconds. If it exceeds, then we have removed insufficient silence.
Since we have this "output" and the bits are located in the opposite direction, we reverse this file (with the "input" we DO NOT reverse (!)). To do the Reverse, click Effects - Reverse:
Save this file, let's say with the name "out.wav":
File type: Windows PCM (* .wav)
Now we do all the above again with the "input" (except for the reverse) and write it down let's say with the name "in.wav".
Opening the program.
We set the following settings in it:
Style: ACM
Header: <blank>
Indent: No
Beginning of line: <blank>
Byte in line: 1
Comments: <blank> (not needed)
Data type: (DEC) 0, 255
Data delimiters: < empty>
Now open in this program our files in.wav and out.wav (button "find") and save them (button "create").
Change the file extensions from * .asm to * .txt and open the files in a standard Windows notebook.
There we will have the following:
; Source file C: \ out.wav
; out 21601 bytes
127
128
127
... Delete the
top three lines, we don't need them. Only the numbers remain in a column.
Now select all the text and copy it to the clipboard.
As you know, when recording information on the magnetic stripe of a plastic card, the so-called F2F coding is used - "Frequency - 2 Frequency", loosely translated "Frequency, doubled frequency", which is a kind of FM coding - "Frequency Modulation" ... In FM there is a signal with constant amplitude (carrier), but changing (modulated) in frequency.
I will try to explain "on the fingers" how information is recorded on the magnetic stripe, and what is F2F modulation.
I will say right away that due to the advanced age of technology, all information on the magnetic stripe is recorded in the "sound" band (20Hz - 20,000 Hz). Naturally, the frequency of the signal on the magnetic stripe will change linearly depending on the speed of the plastic card, but the specification of the standard states that this speed should be from 10 cm to 2 meters per second. At a conduction speed of less than 10 cm / s, the EMF arising on the magnetic head of the reader will be critically low, and at a speed of more than 2 m / s, the signal frequency will go out of range (20,000 Hz, which is 20 kHz). From this it follows that to work with information on a magnetic tape of a plastic card, we will have enough hardware and software for working with sound. A small lyrical digression:
What is F2F modulation? Imagine that at a certain constant speed of the magnetic tape, we have a carrier at, say, 2000 Hz. Let's take it as logical 0. In this case, logical 1 will be equal to twice the frequency of logical 0, which is 4000 Hz. But, since data must be transmitted at a constant speed at a constant speed of the magnetic tape, then log. 1, encoded at twice the frequency, must also have a doubled period. It follows from this that the log. 0 represents a half-cycle, and log. 1 - full period at doubled frequency log. 0.
For clarity, I will give two graphs:
The first graph shows that in a unit of time, the carrier has completed a full period, and in the second graph, it can be seen that in the same unit of time, the carrier has completed only a half period (and the frequency, accordingly, has halved).
Now let's take a graph of a short duration and divide it into equal time intervals (ticks) equal to the duration of a logical zero.
It is absolutely not difficult to determine the information encoded on the chart (11011001011000). Now the question arises: how to actually determine this very duration of a logical zero (clock)? For this purpose, at the beginning and at the end of the magnetic tape there are 10-15 "input" and "output" zeros, which do not carry any information, but only report the duration of the log. 0 and, accordingly, used by the hardware to synchronize the cycle. These lead-in and lead-out zeros are placed on both sides of the magnetic tape, since the tape can be read in both directions, and it must be synchronized before reading the information.
Accordingly, it becomes clear how hardware F2F decoders installed in plastic card readers work:
1) As soon as the decoder “saw” that zeros “went”, it determines the frequency of these logs. 0 (carrier frequency), sets the duration of one "cycle" (one bit of information is transmitted per cycle) and gives a Card Present signal.
2) If the decoder detects that a full period has occurred in one clock cycle, it sends a log. 1, and starts decoding in a similar way the entire track (for one clock - half cycle - log 0, for one clock - full period - log 1).
3) As soon as the decoder loses the carrier, it gives a Card Not Present signal and that's it.
We now understand how an industrial hardware decoder works. We draw conclusions:
1) For synchronization, it necessarily needs input logical zeros, i.e. after stopping while reading the magnetic strip and resuming movement, the decoder will no longer be able to synchronize and will not work. In other words: all information recorded on a magnetic tape after stopping it will be lost. For example, if you stop holding a plastic card in the middle of the magnetic strip, the decoder will give out only half of the information.
2) Changing the speed of the card by at least 25% - and the decoder gets out of sync and sends us to hell, i.e. Card Not Present signal or complete nonsense in the form of incorrectly defined logs. 0 and log. 1.
In everyday circulation, plastic cards are always passed evenly and without interruption, so that the developers and manufacturers of plastic card readers never faced the question “How to read cards with a stop and change in the speed of the card?”. And technically, it is extremely difficult to do it, almost impossible, since at the moment of stopping several bits of information are lost, and there is nowhere to recover them.
Now let's assume the following situation: we have an industrial decoder and the card is drawn with a stop, first in one direction, then in the other direction, also with a stop. (But attention! The change in the speed of conducting should not change by more than 25%, otherwise it will turn out to be complete nonsense.) Accordingly, during the movement "there" we will read the conditionally "right" part of the map, and "back" - the "left" part cards, and we "glue" these two parts, we get a full track. Yes, sometimes it happens, but only sometimes. I explain:
Let's say at the first movement "there" we will have a stop at 50% of the map, respectively. somewhere around 45% will be read, and the remaining 5% will be lost (or get the wrong bits) due to desynchronization during the stop. When moving "back", we will also stop at the same place at 50% of the card, and again only 45% will be read. In total, we will get 45% of the beginning and 45% of the end of the track, but this is not 100%, and, accordingly, the track will not work right for us.
Hence the conclusion: "gluing" from two parts, when using a hardware decoder, is possible only with an even speed of conduction and with an "overlap" of the "input" and "output" movements (for example, at the entrance we get 55% and at the exit 52%), which turns out rarely.
But how, then, to read the "broken" tracks? First, let's forget about the hardware decoders and take a look at the audio recording of the magnetic stripe. We absolutely do not need to synchronize on the input zeros, we, and so straining our logic, purely visually can determine where we have a log. 0 and where is the log. 1. And manually recording 0 and 1, restoring what was lost during the stop from the second movement, we will be able to restore the same "broken" track without problems and errors. But taking into account the order of 200 bits for only Track 2 (and in Track 1 there are generally about 560 of them due to the three times higher recording density), such an occupation is extremely dreary and can drive you crazy. How can we more or less automate this process?
Firstly, we do not need to have an audio recording schedule in front of our eyes, and we only need to know how much time has passed from one peak of a half-period to another peak. Let's go back to our log graph. 0 and log. 1 and conditionally divide one bar into 40 more bars (the 20th bar is highlighted in blue).
From this graph we can see that for the half-period log. 1, it took us 20 cycles and another 20 cycles for the second half-cycle, and for the half-cycle log. 0 it took 40 cycles, i.e. twice more than half-period log.1.
Let's say we have the following "timings" (that's how I conditionally called the number of bars spent on one half-period): 91, 45, 44, 91, 88, 46, 44, 44, 42, 85, 41, 43, 38, 39 , 38, 39, 39, 41, 77, 78, 74, 40, 39 the amount of time spent on one second half-cycle. The volume of one tact is required to know only flax will not work. ... Next, you will find out where it all comes from. Let's try to decode them (remember, log. 0 - half-period, log. 1 - full period (two half-periods at the doubled frequency of half-period log. 0):
91 - it's hard to say, because we don't know the duration of zero yet, but as it turns out in further, this is log.0
45 - half of the duration of the previous timing, this is definitely log.1
44 - and this is the second half-period of the previous log.1
91 - twice as long as the previous timing, log.0
88 - log. 0
46 - log. 1
44 - the second half-period
44 - log. 1
42 - the second half-period
85 - log. 0
41 - log. 1
43 - the second half-period
38 - log. 1
39 - the second half-period
38 - log. 1
39 - the second half-period
39 - log. 1
41 - the second half-period
77 - log. 0
78 - log. 0
74 - log. 0
40 - log. 1
39 - the second half-period
So we get 010011011110001. These timings were "removed" from the real audio recording of the magnetic strip of the plastic card. The audio recording was made with a sampling rate of 44100 Hz, I think you can find such a sampling rate on google.
Accordingly, one clock cycle is equal to 1/44100 of a second, and if we have an average log. 0 is 83 cycles (discrete), then the audio frequency log. 0 in this case, 44100/83 = 531 Hz, and log. 1 respectively 531 * 2 = 1062 Hz. 531 Hz and 1062 Hz are between 20 Hz and 20,000 Hz, which means that the card was drawn at normal speed, within the standard. By the way, in accordance with the Kotelnikov theorem, at a sampling rate of 44100 Hz, the maximum frequency that we can record is 22050 Hz, i.e. the sampling rate of 44100 Hz (the standard sampling rate of audio data on Audio CD) is quite enough for us to digitize information from the magnetic tape of plastic cards.
So, now we know that we can get data bits from the audio recording by calculating the timings between the peaks of the half-waves, and for this we absolutely do not need leading zeros for synchronization, since we, so to speak, "synchronize" every time with each new half-wave. And even if the card is VERY abruptly stopped, it will not stop absolutely instantly, but will stop with some negative acceleration, i.e. duration (number of ticks) of two adjacent half-waves log. 0 will not change by more than 25%, so we can decode this information without any problems.
Decoding of zeros and ones.
I will say right away that in the future there will be a description of decoding only the second track. The first track differs from the second only by a higher recording density and the use of 6 + 1 bits per character.
So, on the second track, we can only have 39 characters + the LRC check character. There are 4 character bits per character + 1 PCB bit (Parity Check Bit), for a total of 5 bits.
The picture above shows the direction of the data. Those. data is written right-to-left.
The data on the second track according to the ISO standard is as follows:
1) Symbol ";", means the beginning of the track
2) 16 numeric characters
3) Symbol "="
4) 20 numeric characters
5) Symbol "?", Means the end of the track
6) LRC check symbol
For example
:; 1234567890123456 = 12345678901234567890? * (* Is LRC)
Bit value table:
If the card is drawn in reverse order (from left to right), then in this table the bits are placed in reverse order: Bit No. 5, Bit # 4 ... Bit # 1.
Now I will explain what a parity bit is: let's take the character "3", it is written as 1100, it contains 2 ones and 2 zeros, and 2 is an even number, respectively, in the parity bit we have 1. Take the character "7" , it is written as 1110, it has 3 ones and 1 zero, and 3 and 1 are odd numbers, therefore in the parity bit we have 0. The parity bit can indicate to us that one of the four bits of a character or a parity bit read incorrectly. For example: if we have 01100, then you can immediately see that 0110 is even, and the parity bit is 0, respectively, one of the bits in this symbol is decoded with an error.
Now let's take a "live" example of timings:
153 - 0
145 - 0
139 - 0
125 - 0
121 - 0
118 - 0
115 - 0
116 - 0
110 - 0
107 - 0
104 - 0
101 - 0
99 - 0
98 - 0
46 - 1
49
47 - 1
47
91 - 0
45 - 1
44
91 - 0
88 - 0
46 - 1
44
44 - 1
42
85 - 0
41 - 1
43
38 - 1
39
38 - 1
39
39 - 1
41
77 - 0
78 - 0
74 - 0
40 - 1
39
37 - 1
38
77 - 0
37 - 1
39
So, we got the following: 0000000000000011010011011110001101.
As we can see, first we have leading zeros, we discard them, and the remaining bits are divided into groups of five bits:
1 1 0 1 0 - ";", the character of the beginning of the second track
0 1 1 0 1 - "6"
1 1 1 0 0 - "7"
0 1 1 0 1 - "6"
I think that everything is very clear and understandable here.
Now I will explain what is behind this cryptic Longitudinal Redundancy Check symbol that runs at the end of the track. Having divided the bits into groups of five in the example above, we consider how many bits No. 1 we have in these four symbols - two bits (even), bits No. 2 - 4 (even), bits No. 3 - 3 (odd), bits No. 4 - 1 (odd), bits # 5 (parity) - 2 (even). If only these four characters were recorded in the second track, then after them, the LRC check bit would follow. It also contains five bits of information, and bit # 5 in the case of the LRC symbol NOT (!) Performs the parity check function. The LRC symbol contains such bits that the total number of all bits of the given number (for example, bits # 1) becomes even. In our example, we see the following:
Bit # 1 - even
Bit # 2 - even
Bit # 3 - odd
Bit # 4 - odd
Bit # 5 - even
Therefore, our LRC symbol will be 00110:
Bit # 1 - 2 + 0 = 2 - even
Bit # 2 - 4 + 0 = 4 - even
Bit # 3 - 3 + 1 = 4 - even
Bit number 4 - 1 + 1 = 2 - even
Bit number 5 - 2 + 0 = 2 - even
I will pay attention once again: LRC symbol in this case looks like 00110, and the number of ones and zeros in the first four bits are even, but bit # 5 is 0. Let me remind you again that in the LRC symbol the fifth bit is not the parity bit of this symbol.
So, if we have any bit from the whole track (but unfortunately, only one bit) is read (or decoded) with an error - by the parity bits, we will determine in which symbol we have an error, and by the LRC symbol we will determine and we will correct the error already inside the erroneous symbol.
Convert WAV to txt
To work with WAV files, we use the program.
By the type of this program, there are also Sound Forge and WaveLab.
So, let's assume that we recorded the second track on a dictaphone with the following parameters (set by default):
Sampling frequency: 22050 Hz
Channels: 1 (Mono)
Bit depth: 16 Bit
Open the wav file in Cool Edit and see the following picture.
In the lower right corner the parameters of our record, which I wrote about above, are indicated.
We see two areas. Apparently (and this will be confirmed later), the first is the "input" (normal bit sequence) card pass, the second "output" (reverse bit sequence) card pass. With a certain skill, the direction of passage of the map can be determined with ease. We also see that the "input" pass was at 48 seconds of recording, and the "output" at 53 seconds. Knowing the start time of the recording, we will know for sure the time of passage of the card.
We see that we have "Exit" with one stop and we will take it as the main one, and we will use the "Entrance" to recover the lost data of the "Exit".
The first thing we do is select the entire "output" and copy it.
Then click in Cool Edit: File - New ...
Set the following parameters for the new file:
44100 Hz, Mono, 8 Bit
Insert into a new file "exit", select the silence at the beginning, end and middle (stop) of the file and delete them with the Delete key.
It turns out the following: We check that the file duration does not exceed 1.4 seconds. If it exceeds, then we have removed insufficient silence.
Since we have this "output" and the bits are located in the opposite direction, we reverse this file (with the "input" we DO NOT reverse (!)). To do the Reverse, click Effects - Reverse:
Save this file, let's say with the name "out.wav":
File type: Windows PCM (* .wav)
Now we do all the above again with the "input" (except for the reverse) and write it down let's say with the name "in.wav".
Opening the program.
We set the following settings in it:
Style: ACM
Header: <blank>
Indent: No
Beginning of line: <blank>
Byte in line: 1
Comments: <blank> (not needed)
Data type: (DEC) 0, 255
Data delimiters: < empty>
Now open in this program our files in.wav and out.wav (button "find") and save them (button "create").
Change the file extensions from * .asm to * .txt and open the files in a standard Windows notebook.
There we will have the following:
; Source file C: \ out.wav
; out 21601 bytes
127
128
127
... Delete the
top three lines, we don't need them. Only the numbers remain in a column.
Now select all the text and copy it to the clipboard.
