I’ve got a new project which I ought to blog about somewhere, and it’s related to file formats, so it’s going here.
There have been projects to archive information about filk songs. They’ve tended toward wikis such as the Filk Discography Wiki, which contains information about filk recordings. Many filk albums have gone out of publication and might otherwise be forgotten, and the wiki keeps them in the cultural memory. Wikis are fine, and they’re easy to participate in with little technical knowledge. They’re also fragile; if the hosting for a wiki goes away, it might find a new home, but it might disappear if no one takes prompt action.
Structured information has advantages. It’s easy for anyone with a little file storage to keep a copy and give it to others. People can create their own repositories, perhaps of songs which they have published. It’s easy to search them and extract information, e.g., all the songs by an author. This isn’t to say that we should abandon wikis, but having structured information as well strengthens the effort. With a little work, it can be fed to wikis.
This is why I’ve created the Argoknot project. It’s a Python-based project to process song data in JSON format. As of this post, it can do one thing: convert CSV files to JSON. I’m planning to add the ability to convert XML files that use the MODS schema. There is a pile of such files in the MASSFILC Filk Book Index.
One of the project’s aims is to create a JSON nomenclature for the filk community. That will let other projects work with the same JSON files to create websites, import into wikis, or do lots of other things.
What I’m doing here is just a start, and it won’t get far without the participation of others. I encourage others in the filk community to join the effort, whether working directly on Argoknot, offering suggestions on how to organize the data, or creating other coding projects.
UPDATE: I’ve enabled discussions on the project and posted an initial message inviting comments and suggestions. So please comment there rather than here if it’s OK with you.
Mad File Format Science 
How broadcast FM can wreck your receiving system
Today I came upon some news weird enough to justify a post on this long-dormant blog. Ars Technica reports that it “began on January 30 and afflicted Mazdas from model years 2014 to 2017 when the cars were tuned to the local NPR station, KUOW 94.9. At some point during the day’s broadcast, a signal from KUOW caused the Mazdas’ infotainment systems to crash—the screens died and the radios were stuck on 94.9 FM.”
That shouldn’t be possible, right? A broadcast FM signal is just frequency-modulated audio. It might deafen you or damage the speakers, but it shouldn’t make the receiver stop working! Well, actually, it isn’t just audio. Broadcasters can optionally use the Radio Broadcast Data System (RBDS), which supports encoded digital data. It uses a 57 kHz subcarrier, well above the limits of human hearing. The data is encoded at 1187.5 bits per second, a strange-sounding number that yields 48 cycles of the subcarrier for every bit. Error correction codes bring the effective data rate down to 730 bits per second.
Continue reading →Comments Off on How broadcast FM can wreck your receiving system
Posted in commentary, News
Tagged radio, software