Most in need of wide space

Edward Giles

Judges' comments:

To use:

make prog
./prog infile.wav outfile.wav

Try:

play MonodyVocals.wav
./prog MonodyVocals.wav
play out.wav

Selected Judges Remarks:

Do you need to pretend enjoying a more spacious living environment than you actually are in, or the great outdoors with mountains and canyons, when recording your outgoing voicemail message? Then don’t waste another minute! Record yourself, send the audio file through this entry, and let your callers be surprised.

Author’s comments:

Description

This program takes a WAV audio file as input, and applies an artificial reverberation effect to it. It works by feeding the audio through a number of delay lines of various lengths, with various amounts of feedback, to create a smooth echo that fades away over time. A number of parameters of the effect can be altered, to change its sonic characteristics.

BlockDiagram.png is a block-diagram of the internal structure of the reverb algorithm, which is most likely easier to understand than the source code.

MonodyVocals.wav is for testing the program: It is an extract of the unprocessed vocals from Monody by TheFatRat, featuring Laura Brehm. The track was published under a free license.

This program has also been successfully compiled on Windows, with both the Tiny C Compiler and Microsoft’s C/C++ compiler. However, the latter reports warnings about loss of information when converting floats, and that void (*)() and void (*)(void) are not the same thing.

Interesting fact: The size of the program from ./iocccsize -i is 2019.

How to use:

./prog input [output [size [dry [wet [damping]]]]]
prog.exe input [output [size [dry [wet [damping]]]]]

The values size, dry, wet, and damping can be specified either as decimal numbers (e.g. 0.35) or as percentages (e.g. 35%).

The default settings are designed to make the effect obvious rather than subtle, so it may be a good idea to adjust the ratio of “dry” to “wet”, to give a more pleasant result:

./prog in.wav out.wav 1.8 80% 15%

The program only supports WAV files, and only mostly. Other audio formats, such as MP3, are not supported because they are difficult to decode, but there are free programs such as ffmpeg that can perform the conversion. Some of the advanced features of the WAV file format are also not supported, such as metadata, 3 or more channels, or a bit depth other than 16 bits. Fortunately, WAV files that don’t use these features are very common. The program validates the input file, so passing it a file it can’t process will cause the program to print Bad input file or Wave file must be 16 bits,1-2 channels. depending on what it thinks the problem is. If the output file cannot be opened, the program will print Can't open output file.

Assumptions

  1. The code is compiled using the C99 or C11 standard
  2. Values are stored in memory in little-endian order
  3. float is a floating-point type of any size, such that all zero bits represents the number zero
  4. int16_t and int32_t are 2’s-complement, sizeof(int16_t) == 2 and sizeof(int32_t) == 4.

Obfuscations

The main obfuscation is that digital signal processing algorithms are inherently opaque. They just consist of iterating through a list of floating-point numbers and performing a series of arithmetic operations on each value. Even if this entry were entirely cleaned of all other obfuscation, it will appear to the average programmer to do the following:

Note that no part of the above description of the code’s function had anything to do with echoes in a room. The purpose of the code is therefore hidden.

The source code, on cursory inspection, appears to be a jumbled series of characters arranged into three arcs, representing sound waves. The overall layout distracts people from the fact that it is source code rather than only ASCII art, and the random appearance of the code discourages people from trying to decipher it.

#defines are used to abbreviate the code, which has a side effect of making it very slightly harder to read.

Every variable name is one letter long. This allows the code to fit into the IOCCC size limit, and it also makes the purpose of a given variable much less clear. For example, it is not evident from the name of the variable t that it contains pointers to the delay-line arrays.

As many values as possible have been crammed into arrays. float w[] contains:

int32_t f[] is even more multi-purpose. It contains:

All of the strings are concatenated together and “encrypted” by breaking the string into 4-byte chunks (by casting it to an int32_t*), and then XORing the sequence of ints with a known numeric sequence. The “decryption” is not done in-place, to avoid writing over the string constant.

int32_t *c is a pointer that points into f[], except that it is often incremented or decremented when it is accessed. In order to determine which indices of f[] are being accessed through c at any given point in the code, you would have to locate the places where c is modified.

In order for this program to read and write WAV files, it needs to parse the header. The necessary information, such as the sample rate and channel count, is defined by the standard to be in somewhat arbitrary locations within the file. Therefore, even if you know which indices of f[] are being accessed, it takes extra effort to look up the WAV file format and determine which field that corresponds to.

Some array accesses (which make up most of the program) have been replaced with harder-to-interpret equivalents, for example:

Assignments return the assigned value, allowing them to be included into later expressions: 10[f]=f[13]<<2; f[1]=20+10[f]+k; is replaced with f[1]=20+(10[f]=f[13]<<2)+k;

This technique is used in conjuction with the comma operator to further obscure where the data ends up. For example,

A few other miscellaneous obfuscations have also been done:


Creative Commons License

© Copyright 1984-2019, Leo Broukhis, Simon Cooper, Landon Curt Noll - All rights reserved
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.