(D)ecode (T)his (M)arketing (F)oolishness
September 30, 2010 9:51 PM Subscribe
I've recently acquired a promotional record that claims to contain a message in coded DTMF tones (mp3). I'm looking for the easiest, most user-friendly way to reliably decode high-speed bursts of DTMF tones. Bonus points for free solutions...
I've tried the most obvious google-result freeware solutions, and even a few iphone apps - I'm looking for a recommendation on something known to work well, or tips for increasing my decoding success?
I've tried the most obvious google-result freeware solutions, and even a few iphone apps - I'm looking for a recommendation on something known to work well, or tips for increasing my decoding success?
From what I understand of the text that you quoted from the rear of the album cover, the DTMF tones are only an audio representation of the 'Identiglyph' that's also printed on the album cover
posted by Venadium at 1:35 AM on October 1, 2010
posted by Venadium at 1:35 AM on October 1, 2010
Response by poster: Thanks zippy, I always forget about slowing down while preserving pitch, I'll give that a shot.
Venadium: that is indeed the claim - I'm interested in confirming how exactly this is done. For example: once I can convert the dtmf tones to data, is that data simply an image file?
posted by adamkempa at 3:57 AM on October 1, 2010
Venadium: that is indeed the claim - I'm interested in confirming how exactly this is done. For example: once I can convert the dtmf tones to data, is that data simply an image file?
posted by adamkempa at 3:57 AM on October 1, 2010
(I've been following this quest on your blog, Adam...if you need to ask another question before this week is over, feel free to MeFiMail me.)
posted by Ian A.T. at 11:09 AM on October 1, 2010
posted by Ian A.T. at 11:09 AM on October 1, 2010
Best answer: I've been working on this in my spare time and I've come to a working solution to decode it.
If you look at the audio in a program like audacity you can see that each symbol is about 17.7 ms in duration, and based on the total clip length there should therefore be approximately 22000 of them. There is about 1 ms of dead time where the signal is zero or near-zero between each symbol. This discontinuity explains the buzzing background noise that you hear, because those sharp edges every 17.7 ms create a hum at 56.5 Hz and its harmonics. Using a spectral analysis tool like baudline shows those harmonics as well as the tones. It also explains why you've been having difficulty getting DTMF programs to work, because they used slightly different frequencies which means that normal DTMF programs would probably read nonsense, if anything.
Standard DTMF uses rows of (697, 770, 852, 941) and columns of (1209, 1336, 1477). Using baudline I measured the tones used here as (636, 709, 785, 862) and (1109, 1228, 1357). I then wrote a perl script to take advantage of the fact that each symbol was separated by a short run of zeros to break the clip into individual symbols and then FFT each one. Each symbol is approximately 725 samples long, not counting the zero runs, and I chose a FFT length of 2048 (with Hamming windowing) which means each bucket was 21.5 Hz wide, which was good enough with a little massaging to easily read each symbol. The nearest bucket center frequencies worked out to (635, 700, 764, 851) and (1109, 1217, 1346) which meant they were close enough that I was able to just read out the bucket with the highest power density in each range without having to do anything more sophisticated like interpolation or peak detection.
This is the script. I apologize for the amount of commented out debugging junk still left in there, it's still in a rough state. It requires the perl module Math::FFT installed as well as the sox command line utility for reading the wav file, which is prepared as:
$ sox brand_labs_audiosonic_identiglyph_LEFT_CHANNEL_ONLY.mp3 -c 1 mono.wav avg -l trim 00:01.231178
This simply uncompresses the mp3 file, selects the left channel to make a mono file and trims the initial junk at the beginning. Then
$ ./identiglyph.pl mono.wav
This processes the file and decodes each symbol (22221 in total), writing them to the file identiglyph.out. As you can see it's readily apparent that every three digits forms an 8 bit octet, so to convert to binary I used:
$ perl -ne 'for(my $i = 0; $i < length; $i+=3) { push @arr, int(substr($_, $i, 3)); } print pack("C*", @arr); ' <identiglyph.out >identiglyph.bin
$ file identiglyph.bin
identiglyph.bin: JPEG image data, JFIF standard 1.02
Ah, we have an image. Rename to .jpg and this is the result. I see on your blog that you've already figured out that the fins spell out GPS coordinates of their office, so I guess that's about it.
posted by Rhomboid at 2:05 AM on October 3, 2010 [2 favorites]
If you look at the audio in a program like audacity you can see that each symbol is about 17.7 ms in duration, and based on the total clip length there should therefore be approximately 22000 of them. There is about 1 ms of dead time where the signal is zero or near-zero between each symbol. This discontinuity explains the buzzing background noise that you hear, because those sharp edges every 17.7 ms create a hum at 56.5 Hz and its harmonics. Using a spectral analysis tool like baudline shows those harmonics as well as the tones. It also explains why you've been having difficulty getting DTMF programs to work, because they used slightly different frequencies which means that normal DTMF programs would probably read nonsense, if anything.
Standard DTMF uses rows of (697, 770, 852, 941) and columns of (1209, 1336, 1477). Using baudline I measured the tones used here as (636, 709, 785, 862) and (1109, 1228, 1357). I then wrote a perl script to take advantage of the fact that each symbol was separated by a short run of zeros to break the clip into individual symbols and then FFT each one. Each symbol is approximately 725 samples long, not counting the zero runs, and I chose a FFT length of 2048 (with Hamming windowing) which means each bucket was 21.5 Hz wide, which was good enough with a little massaging to easily read each symbol. The nearest bucket center frequencies worked out to (635, 700, 764, 851) and (1109, 1217, 1346) which meant they were close enough that I was able to just read out the bucket with the highest power density in each range without having to do anything more sophisticated like interpolation or peak detection.
This is the script. I apologize for the amount of commented out debugging junk still left in there, it's still in a rough state. It requires the perl module Math::FFT installed as well as the sox command line utility for reading the wav file, which is prepared as:
$ sox brand_labs_audiosonic_identiglyph_LEFT_CHANNEL_ONLY.mp3 -c 1 mono.wav avg -l trim 00:01.231178
This simply uncompresses the mp3 file, selects the left channel to make a mono file and trims the initial junk at the beginning. Then
$ ./identiglyph.pl mono.wav
This processes the file and decodes each symbol (22221 in total), writing them to the file identiglyph.out. As you can see it's readily apparent that every three digits forms an 8 bit octet, so to convert to binary I used:
$ perl -ne 'for(my $i = 0; $i < length; $i+=3) { push @arr, int(substr($_, $i, 3)); } print pack("C*", @arr); ' <identiglyph.out >identiglyph.bin
$ file identiglyph.bin
identiglyph.bin: JPEG image data, JFIF standard 1.02
Ah, we have an image. Rename to .jpg and this is the result. I see on your blog that you've already figured out that the fins spell out GPS coordinates of their office, so I guess that's about it.
posted by Rhomboid at 2:05 AM on October 3, 2010 [2 favorites]
Best answer: (Apparently imgur.com is doing some kind of re-packing of the image because it's a different length than the one I uploaded. 22221 / 3 = 7407 bytes. Here is another copy that is the correct length and hasn't been corrupted, if you're verifying.)
posted by Rhomboid at 2:46 AM on October 3, 2010
posted by Rhomboid at 2:46 AM on October 3, 2010
Response by poster: Wow, Rhomboid - you win the internet. Drop me a line and I'll send you a copy of the record if you're interested!
posted by adamkempa at 6:47 PM on October 3, 2010
posted by adamkempa at 6:47 PM on October 3, 2010
Thanks Rhomboid.
Trying to decode that was giving me nightmares.
posted by sid.tv at 2:42 AM on October 4, 2010
Trying to decode that was giving me nightmares.
posted by sid.tv at 2:42 AM on October 4, 2010
This thread is closed to new comments.
posted by zippy at 10:41 PM on September 30, 2010