Files
ioccc/2014/vik/README.md
T
Cody Boone Ferguson 249e865de2 Mass edit README.md: remove top award/author lines
As requested on GitHub: a tool that will be written, readme2index, will,
as explained:

    '... will take the converted HTML from the README.md markdown and
    inject it into an HTML template. Things such title, award one and
    author information will be injected into the HTML page ahead of the
    HTML that was converted from the README.md markdown. Without going
    into details of HOW at this time, the result will be a coherent HTML
    index.html page with the winner title / award, winning author
    information, and important file links come from other sources and
    NOT from the README.md file.

    The text from the 1st award line, thru the authorship information,
    and up to but not including the "## To build:" line in the README.md
    file will just get in the way. Moreover authors might be tempted to
    try and maintain that top of README.md text instead of working with
    the author/_author_handle_.json and winner .winner.json files.

This was done with my[0] sgit(1) (https://github.com/xexyl/sgit) tool like:

    sgit -o -n -e '/^## To build:/,$p' '[12][0-9][0-9][0-9]/*/README.md'

[0] Is that shameless self-promotion? I don't know but I don't care: it
is generally a very useful tool and has been used in other repos too.
Besides, I've done it many times before and it's a great example that I
will be adding to the README.md file of the tool, one I hadn't thought
of doing.
2023-11-05 03:39:46 -08:00

3.3 KiB

To build:

make

Bugs and (Mis)features:

The current status of this entry is:

STATUS: known bug - please help us fix

For more detailed information see 2014 vik in bugs.md.

To use:

./prog > foo.c

There is an alternate version that will theoretically work with Windows compilers (if anything in Windows works :-) ). See the Alternate code section below.

Try:

echo 'Want to hear me beep?' | ./prog > audio_file.raw

echo 'No. I want chocolate!' | ./prog | mplayer -demuxer rawaudio -

Alternate code:

The alternate code, prog.alt.c, is based on the author's instructions on how to get it to work with Windows. This has not been tested but in order to use it you can do:

make alt

Use prog.alt as you would prog above as well as below.

Judges' remarks:

This program sets a new tone for obfuscation. But do you understand what it says about obfuscation? Perhaps:

./prog < prog.c > prog.raw

might speak to your coding style? If not, then perhaps:

./prog < README.md | mplayer -demuxer rawaudio -

might help? :-)

Author's remarks:

Remarks

This program converts ascii text to Morse audio file and vice versa. As far as I can tell, there are at least six chocolate references in this program.

This program can convert text to Morse to a raw 44.1kHz stereo audio file. Via streaming to mplayer, you can listen to the Morse audio.

Don't forget the last '-' as it makes mplayer read from stdin.

Convert audio file with Morse signals to text

./prog e < audio_file.raw

or alternatively pass a .wav file as input.

The preferred input format 44.1kHz stereo, but it does a decent job on mono input and different frequencies as well.

Portability

The program is portable to most platforms. The only system dependency is that the program relies on writing binary data to stdout.

Microsoft compilers add a carriage return to newlines, and to compile the program with this platform, the following line can be added after the main declaration in order for the program to run correctly:

_setmode(_fileno(stdout), 0x8000);

NOTE: see the alternate code for this.

Known Issues

The program uses a quite simple algorithm for detecting tone on and off events in the Morse signal. Hence the program does not work well with noisy input signals. I have tested it with several samples of man made Morse recordings as well as computer generated ones.

Generally, any recording from ham radio transmissions does not decode due to noise and echoes. Other man made recordings may decode, but some characters can be incorrect due to too big variation in length of tones and pauses. However I found some man made recordings on that decode reasonable well.

If a recording doesn't decode, you could try to pre-process the input with a narrow bandpass filter on the frequency of the transmission.

This file is Copyright (c) 2023 by Landon Curt Noll. All Rights Reserved. You are free to share and adapt this file under the terms of this license:

Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)

For more information, see: https://creativecommons.org/licenses/by-sa/4.0/