Läs alla magnetremsa kort med en fyrkantig läsare och en Android-enhet (4 / 5 steg)

Steg 4: avkoda ljud

Så, nu har vi fått en massa ljud på vår enhet. Hur vi avkodar det? Jag bygger min kod på en Android tutorial som visar hur man spela in data och sedan spela upp den. I mitt fall såg jag till att spara det ljudet som 16-bitars PCM-kodat. Jag provtas på 44100hz. På Android (och på andra håll, antar jag) 16-bitars PCM data innebär att varje prov är ett signerat 16-bitars värde. Eftersom vi bara bryr sig om frekvensen, behöver vi bara bryr sig om hur mycket tid det är mellan "noll-korsningar". En noll-korsning är när signalen går från postive till negativa eller vice versa. Lite 0 kommer att företrädas av utrymmet mellan 2 korsningar, och en 1 kommer att ha en extra passage i ungefär samma tidsperiod.
Kortdata i varje spår som inleds med några (variabel) antal 0s, att upprätta bas frekvensen. Vad jag gjorde var lyssna för det första provet ovanför en viss "tyst" tröskel och sedan räkna antalet prover mellan noll-korsningar. Detta nummer blir basvärde för en 0. Eftersom dessa kort är hand-swiped, ändras de faktiska frekvenserna något från början av sökningen till slutet. Så gjorde jag en enkel metod som avgör om antalet prov sedan den senaste noll-korsningen är närmare basen frekvensen eller dubbelt baserafrekvens (halv bas antalet prover). Det justerar sedan den förväntade baserafrekvens därefter. Detta fungerar bra, så länge förändringarna mellan de två logiska bitarna är ganska små. Och de nästan säkert kommer att vara.

För att upptäcka en noll-korsning, måste vi titta på tecken på varje prov och jämföra det med tecknet för föregående prov.. Om de skiljer sig åt (ett positivt, en negativ) korsade signalen 0 mellan dessa prover.

Den grundläggande algoritmen är att iterera genom bytearrayen, extrahera prover. Räkna antalet prover mellan noll-korsningar och jämför räkningen till antalet förväntade för en 0 eller 1.

Okej, efter några hand-waving har vi nu en binär sekvens av data, vilket vi vill vända tillbaka in i ASCII. Den vanligaste kodning (och den enda jag skrev en hanterare för) kodar varje tecken som ett antal bitar, plus en paritetsbit. När det gäller spår 2, som är 4 bitar för karaktären, och 1 för paritet, att göra 5 bit grupper. Bitarna Läs från minst signifikanta för de flesta, med paritetsbiten senast. Paritetsbiten är inställd på att antalet 1s i gruppen udda. I min genomförande, jag bortse från bara paritetsbiten, men det skulle hjälpa avgöra om Läs var bra eller inte. Spår 1 är det 6 bitar för karaktären, plus paritet.
Teckenet-uppsättning av spåren skiljer sig också, men båda är delmängder av ASCII med vissa offset. När det gäller spår 2, som kodar endast några symboler och siffror, börjar teckenuppsättningen på 48, vilket är ASCII-koden för "0". Så om vi får 0,0,0,0,1 som vår karaktär, vi förvandla det till 0, lägga till 48 och få 48. Likaså är 1,0,0,0,0 1. 1 + 48 = 49 = ASCII "1".
För spår 1, den teckenuppsättning som börjar med "" (blanksteg) som är ASCII-32. Så vi lägger till 32 avkodade numeriska värdet och få våra ASCII-tecken. Efter det har vi data, så alla att resterna upphakning UI limmet.