mirror/ioccc
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add preview of 1984-2019

Browse Source 
The 2020 winners are hinted it, but the source code is not there,
nor are the hints. Someone could look into the HTML and
see what was commented out, but that is not a problem because
WHO won is known and the name of their AWARD is known already.
Moreover a number of the winners have talked about what their
entirs do, so the commented out spoiler text is not a bit problem.

One will find HTML commented out with:

    <!-- XXX remove when 2020 is ready
    2020 links here
    XXX remove when 2020 is ready -->

The "XXX remove when 2020 is ready" string is found at the
start and end comment blocks.  Again, soneone could read
what was commented out, but that is OK since most of that
information is known or can be known.  The following files
have such HTML comment blocks in them.

    ./winners.html
    ./years-spoiler.html
    ./years.html

In addition, ./all/summary.txt was modified to not
include the 2020 entries for the momemt.

The 2020 winner code AND write-ups are NOT part of this set.

p.s. The all/all.tar.bz2 does not contain the 2020 source code (yet?).
This commit is contained in:
Landon Curt Noll committed 2020-12-30 16:57:03 -08:00
1 parent 28efc67f5d
commit c0663537cb
1683 files changed
+220064
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

2019/giles/BlockDiagram.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 33 KiB

2019/giles/Makefile
+526
View File
@@ -0,0 +1,526 @@
#!/usr/bin/env make
#
# 2019 makefile
#
# This work by Landon Curt Noll, Simon Cooper, and Leonid A. Broukhis
# is licensed under:
#
# Creative Commons Attribution-ShareAlike 3.0 Unported License.
#
# See: http://creativecommons.org/licenses/by-sa/3.0/
#############################
# shell used by this Makefile
#############################
#
SHELL= /bin/bash
#######################
# common tool locations
#######################
#
A2P= a2p
AR= ar
ASA= asa
AT= at
ATQ= atq
ATRM= atrm
AWK= awk
BANNER= banner
BASE64= base64
BASENAME= basename
BATCH= batch
BC= bc
BINHEX= binhex
BISON= bison
BUNZIP2= bunzip2
BZCAT= bzcat
BZCMP= bzcmp
BZDIFF= bzdiff
BZEGREP= bzegrep
BZFGREP= bzfgrep
BZGREP= bzgrep
BZIP2= bzip2
BZLESS= bzless
BZMORE= bzmore
C2PH= c2ph
C89= c89
C99= c99
CAL= cal
CALC= calc
CAT= cat
CD= cd
CHFLAGS= chflags
CHGRP= chgrp
CHMOD= chmod
CKSUM= cksum
CLANG= clang
CLANG_PLUSPLUS= clang++
CLEAR= clear
CMP= cmp
COL= col
COLLDEF= colldef
COLRM= colrm
COLUMN= column
COMPRESS= compress
CP= cp
CPIO= cpio
CPP= cpp
CRC32= crc32
CSH= csh
CSPLIT= csplit
CURL= curl
CUT= cut
C_PLUSPLUS= c++
C_PLUSPLUS_FILT= c++filt
DATE= date
DC= dc
DD= dd
DF= df
DIFF3= diff3
DIFF= diff
DIG= dig
DIRNAME= dirname
ED= ed
EGREP= egrep
ENV= env
EQN= eqn
ETAGS= etags
EXPECT= expect
EXPR= expr
FALSE= false
FGREP= fgrep
FILE= file
FIND2PERL= find2perl
FIND= find
FLEX= flex
FLEX_PLUSPLUS= flex++
FMT= fmt
FOLD= fold
FS_USAGE= fs_usage
FUNZIP= funzip
FUSER= fuser
GCC= gcc
GDIFFMK= gdiffmk
GENCAT= gencat
GENSTRINGS= genstrings
GETOPT= getopt
GETOPTS= getopts
GNUMAKE= gnumake
GREP= grep
GROFF= groff
GROFFER= groffer
GROG= grog
GROPS= grops
GROTTY= grotty
GUNZIP= gunzip
GVIM= gvim
GZCAT= gzcat
GZEXE= gzexe
GZIP_PROG= gzip
G_PLUSPLUS= g++
H2PH= h2ph
H2XS= h2xs
HASH= hash
HEAD= head
HOSTNAME_PROG= hostname
ICONV= iconv
ID= id
INDENT= indent
INFO= info
JOT= jot
KILL= kill
KSH= ksh
LAST= last
LD= ld
LESSECHO= lessecho
LEX= len
LINK= link
LN= ln
LS= ls
M4= m4
MAKE= make
MAN= man
MKDIR= mkdir
MKFIFo= mkfifo
MKTEMP= mktemp
MV= mv
NANO= nano
NASM= nasm
NEQN= neqn
NICE= nice
NL= nl
NM= nm
NOHUP= nohup
NROFF= nroff
NSLOOKUP= nslookup
OD= od
OPENSSL= openssl
PASTE= paste
PATCH= patch
PATHCHK= pathchk
PAX= pax
PERL= perl
PICO= pico
PR= pr
PRINTENV= printenv
PS= ps
PTAR= ptar
PTARDIFF= ptardiff
PTARGREP= ptargrep
PWD= pwd
PYDOC= pydoc
PYTHON= python
PYTHONW= pythonw
READLINK= readlink
RENICE= renice
RESET= reset
REV= rev
RI= ri
RM= rm
RMDIR= rmdir
RSYNC= rsync
RUBY= ruby
RVIM= rvim
SAY= say
SCP= scp
SCREEN= screen
SCRIPT= script
SDIFF= sdiff
SED= sed
SEQ= seq
SFTP= sftp
SH= sh
SHA1= sha1
SHA= sha
SHAR= shar
SHASUM5_18= shasum5.18
SHASUM= shasum
SIZE= size
SLEEP= sleep
SORT= sort
SSH= ssh
STAT= stat
STRIP= strip
STTY= stty
SUM= sum
SYNC= sync
TABS= tabs
TAIL= tail
TAR= tar
TEE= tee
TEST= test
TFTP= tftp
TIDY= tidy
TIME= time
TOP= top
TOUCH= touch
TPUT= tout
TPUT= tput
TR= tr
TROFF= troff
TRUE= true
TSET= tset
TSORT= tsort
UL= ul
UNAME= uname
UNCOMPRESS= uncompress
UNEXPAND= unexpand
UNIFDEF= unifdef
UNIFDEFALL= unifdefall
UNIQ= uniq
UNITS= units
UNLINK= unlink
UNZIP= unzip
UNZIPSFX= unzipsfx
UPTIME= uptime
UUDECODE= uudecode
UUENCODE= uuencode
UUIDGEN= uuidgen
VI= vi
VIEW= view
VIM= vim
VIMDIFF= vimdiff
W= w
WAIT4PATH= wait4path
WAIT= wait
WC= wc
WHAT= what
WHATIS= whatis
WHICH= which
WHO= who
WHOAMI= whoami
WHOIS= whois
WRTIE= write
XAR= xar
XARGS= xargs
XATTR= xattr
XXD= xxd
YACC= yacc
YES= yes
ZCAT= zcat
ZCMP= zcmp
ZDIFF= zdiff
ZEGREP= zegrep
ZFGREP= zfgrep
ZFORCE= zforce
ZGREP= zgrep
ZIP= zip
ZIPCLOAK= zipcloak
ZIPGREp= zipgrep
ZIPINFo= zipinfo
ZIPNOTE= zipnote
ZIPSPLIT= zipsplit
ZLESS= zless
ZMORE= zmore
ZNEW= znew
ZPRINT= zprint
ZSH= zsh
# Set X11_LIBDIR to the directory where the X11 library resides
#
#X11_LIBDIR= /usr/X11R6/lib
#X11_LIBDIR= /usr/X11/lib
X11_LIBDIR= /opt/X11/lib
# Set X11_INCLUDEDIR to the directory where the X11 include files reside
#
#X11_INCDIR= /usr/X11R6/include
#X11_INCDIR= /usr/X11/include
X11_INCDIR= /opt/X11/include
# Compiler warnings
#
#CWARN=
#CWARN= -Wall
#CWARN= -Wall -Wextra
CWARN= -Wall -Wextra -pedantic ${CSILENCE}
#CWARN= -Wall -Wextra -Weverything
#CWARN= -Wall -Wextra -Weverything -pedantic
#CWARN= -Wall -Wextra -Weverything -pedantic ${CSILENCE}
# Silence warnings that ${CWARN} would normally complain about
#
#CSILENCE=
#CSILENCE= -Wno-implicit-int
CSILENCE= -Wno-empty-body
# compiler standard
#
#CSTD=
#CSTD= -ansi
#CSTD= -std=c11
CSTD= -std=c99
# compiler bit architecture
#
# Some entries require 32-bitness:
# ARCH= -m32
#
# Some entries require 64-bitness:
# ARCH= -m64
#
# By default we assume nothing:
#
ARCH=
# defines that are needed to compile
#
CDEFINE=
#CDEFINE= -DIOCCC=26
# include files that are needed to compile
#
CINCLUDE=
#CINCLUDE= -include stdlib.h
#CINCLUDE= -include stdio.h
#CINCLUDE= -include stdlib.h -include stdio.h
#CINCLUDE= -I ${X11_INCDIR}
# optimization
#
# Most compiles will safely use -O2. Some can use only -O1 or -O.
# A few compilers have broken optimizers or this entry make break
# under those buggy optimizers and thus you may not want anything.
# Reasonable compilers will allow for -O3.
#
#OPT=
#OPT= -O
#OPT= -O1
#OPT= -O2
OPT= -O3
# default flags for ANSI C compilation
#
CFLAGS= ${CSTD} ${CWARN} ${ARCH} ${CDEFINE} ${CINCLUDE} ${OPT}
# Libraries needed to build
#
LIBS=
#LIBS= -L ${X11_LIBDIR}
# ANSI compiler
#
# Set CC to the name of your ANSI compiler.
#
# Some entries seem to need gcc. If you have gcc, set
# both CC and MAY_NEED_GCC to gcc.
#
# If you do not have gcc, set CC to the name of your ANSI compiler, and
# set MAY_NEED_GCC to either ${CC} (and hope for the best) or to just :
# to disable such programs.
#
CC= cc
#CC=clang
MAY_NEED_GCC= gcc
##############################
# Special flags for this entry
##############################
#
OBJ= prog.o
DATA=
TARGET= prog
#
ALT_OBJ=
ALT_TARGET=
#################
# build the entry
#################
#
all: ${TARGET} ${DATA}
@${TRUE}
prog: prog.c
${CC} ${CFLAGS} $< -o $@ ${LIBS}
# alternative executable
#
alt: ${ALT_TARGET}
@${TRUE}
# data files
#
data: ${DATA}
@${TRUE}
###############
# utility rules
###############
#
everything: all alt
clean:
${RM} -f ${OBJ} ${ALT_OBJ}
clobber: clean
${RM} -f ${TARGET} ${ALT_TARGET}
@-if [ -e sandwich ]; then \
${RM} -f sandwich; \
echo 'ate sandwich'; \
fi
nuke: clobber
@${TRUE}
dist_clean: nuke
@${TRUE}
install:
@echo "Surely you are performing, Dr. May!"
@${TRUE}
# backwards compatibility
#
build: all
@${TRUE}
##################
# 133t hacker rulz
##################
#
love:
@echo 'not war?'
@${TRUE}
haste:
$(MAKE) waste
@${TRUE}
waste:
@echo 'haste'
@${TRUE}
make:
@echo 'Attend a maker faire'
@${TRUE}
easter_egg:
@echo you expected to often mis-understand this $${RANDOM} magic
@echo chongo '<was here>' "/\\oo/\\"
@echo Eggy
fabricate fashion form frame manufacture produce: make
@${TRUE}
sandwich:
@if [ `id -u` -eq 0 ]; then \
echo 'Okay.'; \
echo $${RANDOM}`date +%s`$${RANDOM} > $@; \
else \
echo 'What? Make it yourself.'; \
exit 1; \
fi
# Understand the history of the Homebrew Computer Club
# as well as the West Coast Computer Faire and
# you might be confused different. :-)
#
supernova: nuke
@-if [ -r .code_anal ]; then \
${RM} -f .code_anal_v6; \
else \
echo "planet deniers, like some members of the IAU, are so cute when they try to defend their logic"; \
fi
@echo A $@ helps ${MAKE} the elements that help form planets
@${TRUE}
deep_magic:
@-if [ -r .code_anal ]; then \
ccode_analysis --deep_magic fc6b6af226b7cc598de3d48fc20ed0bd54f7b4f7f0f651a32b9cf8345b2a3b3f --FNV1a_hash_512_bit "prog"; \
else \
echo "Wrong! Do it again!"; \
sleep 2; \
echo "Wrong! Do it again!"; \
sleep 2; \
echo "Wrong! Do it again!"; \
fi
@${TRUE}
magic: deep_magic
@-if [ -r .code_anal ]; then \
ccode_analysis --level 391581 --mode 216193 --FNV1a_hash_512_bit "prog"; \
else \
echo "If you don't eat yer meat, you can't have any pudding!"; \
echo "How can you have any pudding if you don't eat yer meat?!"; \
fi
@${TRUE}
# The IOCCC resident astronomer states
#
charon: supernova
@echo $@ is a dwarf planet
@echo dwarf is a type of planet
@echo therefore IAU, $@ is a planet
pluto: supernova
${MAKE} charon
@echo $@ is a dwarf planet
@echo dwarf is a type of planet
@echo therefore, $@ is a planet
@echo get used to having lots of planets because a $< can ${MAKE} a lot of them
2019/giles/MonodyVocals.wav
BIN
View File
Binary file not shown.
2019/giles/hint.html
+200
View File
@@ -0,0 +1,200 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta name="GENERATOR" content="mkd2html 2.2.0">
<meta http-equiv="Content-Type"
content="text/html; charset=utf-8"> <link rel="stylesheet"
type="text/css"
href="../hint.css">
<title>Most in need of wide space</title>
</head>
<body>
<h1>Most in need of wide space</h1>
<p>Edward Giles</p>
<h2>Judges' comments:</h2>
<h3>To use:</h3>
<pre><code>make prog
./prog infile.wav outfile.wav
</code></pre>
<h3>Try:</h3>
<pre><code>play MonodyVocals.wav
./prog MonodyVocals.wav
play out.wav
</code></pre>
<h3>Selected Judges Remarks:</h3>
<p>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&rsquo;t waste another minute! Record yourself, send the audio file through this entry,
and let your callers be surprised.</p>
<h2>Author&rsquo;s comments:</h2>
<h2>Description</h2>
<p>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.</p>
<p>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.</p>
<p>MonodyVocals.wav is for testing the program: It is an extract of the unprocessed vocals from <a href="https://www.youtube.com/watch?v=B7xai5u_tnk">Monody by TheFatRat, featuring Laura Brehm</a>. The track was published under a free license.</p>
<p>This program has also been successfully compiled on Windows, with both the <a href="https://bellard.org/tcc/">Tiny C Compiler</a> and Microsoft&rsquo;s C/C++ compiler. However, the latter reports warnings about loss of information when converting floats, and that <code>void (*)()</code> and <code>void (*)(void)</code> are not the same thing.</p>
<p>Interesting fact: The size of the program from <code>./iocccsize -i</code> is 2019.</p>
<p><strong>How to use</strong>:</p>
<pre><code>./prog input [output [size [dry [wet [damping]]]]]
prog.exe input [output [size [dry [wet [damping]]]]]
</code></pre>
<ul>
<li><code>input</code>: The path to the input file. Required.</li>
<li><code>output</code>: The path to the output file. Optional, defaults to <code>out.wav</code>.</li>
<li><code>size</code>: The perceived size of the room, i.e. the approximate amount of time taken for the echo to fade away. Optional, default 1.6 seconds.</li>
<li><code>dry</code>: The amount of unprocessed signal (&ldquo;dry&rdquo; in audio terminology) to add to the output. Optional, default 0.3 or 30%.</li>
<li><code>wet</code>: The amount of processed (&ldquo;wet&rdquo;) signal to add to the output. Optional, default 0.5 or 50%.</li>
<li><code>damping</code>: The amount by which high frequencies are damped out as the echo continues. This models the tendency for higher frequencies to be absorbed more than lower ones. Increasing this value causes the echo to be less &ldquo;harsh&rdquo; and more &ldquo;muffled&rdquo;. Optional, default 0.06 or 6%.</li>
</ul>
<p>The values <code>size</code>, <code>dry</code>, <code>wet</code>, and <code>damping</code> can be specified either as decimal numbers (e.g. 0.35) or as percentages (e.g. 35%).</p>
<p>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 &ldquo;dry&rdquo; to &ldquo;wet&rdquo;, to give a more pleasant result:</p>
<pre><code>./prog in.wav out.wav 1.8 80% 15%
</code></pre>
<p>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 <code>ffmpeg</code> 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&rsquo;t use these features are very common. The program validates the input file, so passing it a file it can&rsquo;t process will cause the program to print <code>Bad input file</code> or <code>Wave file must be 16 bits,1-2 channels.</code> depending on what it thinks the problem is. If the output file cannot be opened, the program will print <code>Can't open output file</code>.</p>
<h2>Assumptions</h2>
<ol>
<li>The code is compiled using the C99 or C11 standard</li>
<li>Values are stored in memory in little-endian order</li>
<li><code>float</code> is a floating-point type of any size, such that all zero bits represents the number zero</li>
<li><code>int16_t</code> and <code>int32_t</code> are 2&rsquo;s-complement, <code>sizeof(int16_t) == 2</code> and <code>sizeof(int32_t) == 4</code>.</li>
</ol>
<h2>Obfuscations</h2>
<p>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:</p>
<ul>
<li>Read and validate command-line arguments.</li>
<li>Read and validate the header portion of the input file, and print some errors if that fails.</li>
<li>Write a modified form of that header into the output file.</li>
<li>Print the parameters read from the command-line arguments, in a human-readable format.</li>
<li>Dynamically allocate some arrays of floating-point numbers, to be used later, with lengths based on the <code>size</code> parameter</li>
<li>Read 16-bit audio samples from the input file, converting them to floating-point.</li>
<li>For each audio sample, do a weird combination of addition, subtraction, and multiplication by constants, using the previously-allocated arrays to store results between iterations. Write the resulting audio samples to the output file, converting them back to 16-bit integers.</li>
<li>Close all of the file handles and free the memory.</li>
</ul>
<p>Note that no part of the above description of the code&rsquo;s function had anything to do with echoes in a room. The purpose of the code is therefore hidden.</p>
<p>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.</p>
<p><code>#define</code>s are used to abbreviate the code, which has a side effect of making it very slightly harder to read.</p>
<ul>
<li><code>k</code> is just a general-purpose replacement for 16.</li>
<li><code>i</code> is the number of delay-lines to allocate and use (currently 24).</li>
<li><code>q</code> is an abbreviation for multiplying two elements of <code>w[]</code> together.</li>
<li><code>u()</code> is used to display percentages with proper rounding.</li>
<li><code>j()</code> imposes an upper limit on a floating-point value, and then negates it. This operation is used eight times.</li>
<li><code>D()</code> abbreviates a call to <code>setvbuf</code>, used to speed up file I/O.</li>
<li><code>l()</code> is used to clip audio samples to the acceptable range, and convert them to 16-bit integers for output.</li>
<li><code>g()</code> handles errors.</li>
<li><code>C()</code> contains the bulk of the signal-processing code, as well as a preprocessor obfuscation trick: If you were to read the body of the macro out of context, it will appear to have multiple mismatched square brackets, since <code>[</code> occurs more than <code>]</code>. However, this macro is always invoked with arguments such as <code>C(v],+10)</code> which contain an unmatched <code>]</code> character. When the macro is used in this manner, the extra <code>[</code>s in the macro&rsquo;s body are matched with the <code>]</code>s added through the first argument.</li>
</ul>
<p>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 <code>t</code> that it contains pointers to the delay-line arrays.</p>
<p>As many values as possible have been crammed into arrays. <code>float w[]</code> contains:</p>
<ul>
<li>the input parameters (<code>w[0]</code> to <code>w[3]</code>)</li>
<li>various constants needed for the reverb algorithm (<code>w[4]</code> to <code>w[9]</code>)</li>
<li>temporary storage of floating-point audio samples (<code>w[10]</code> to <code>w[20]</code>)</li>
</ul>
<p><code>int32_t f[]</code> is even more multi-purpose. It contains:</p>
<ul>
<li>the header of the input file (<code>f[0]</code> to <code>f[11]</code>)</li>
<li>the number of channels in the input file (<code>f[12]</code>)</li>
<li>the number of samples of output to generate (<code>f[13]</code>)</li>
<li>an end-of-file flag (<code>f[14]</code>)</li>
<li>a variable that I forgot the exact purpose of (<code>f[15]</code>)</li>
<li>indices into the circular buffers where audio samples should be inserted (<code>f[16]</code> to <code>f[39]</code>)</li>
<li>indices where audio samples should be read out (<code>f[40]</code> to <code>f[63]</code>)</li>
<li>lengths of the buffers (<code>f[64]</code> to <code>f[87]</code>)</li>
</ul>
<p>All of the strings are concatenated together and &ldquo;encrypted&rdquo; by breaking the string into 4-byte chunks (by casting it to an <code>int32_t*</code>), and then XORing the sequence of ints with a known numeric sequence. The &ldquo;decryption&rdquo; is not done in-place, to avoid writing over the string constant.</p>
<p><code>int32_t *c</code> is a pointer that points into <code>f[]</code>, except that it is often incremented or decremented when it is accessed. In order to determine which indices of <code>f[]</code> are being accessed through <code>c</code> at any given point in the code, you would have to locate the places where <code>c</code> is modified.</p>
<p>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 <code>f[]</code> are being accessed, it takes extra effort to look up the WAV file format and determine which field that corresponds to.</p>
<p>Some array accesses (which make up most of the program) have been replaced with harder-to-interpret equivalents, for example:</p>
<ul>
<li><code>X[1]</code> -> <code>1[X]</code></li>
<li><code>f[14]</code> -> <code>10[f+4]</code></li>
<li><code>X[0]</code> -> <code>*X</code></li>
</ul>
<p>Assignments return the assigned value, allowing them to be included into later expressions: <code>10[f]=f[13]&lt;&lt;2; f[1]=20+10[f]+k;</code> is replaced with <code>f[1]=20+(10[f]=f[13]&lt;&lt;2)+k;</code></p>
<p>This technique is used in conjuction with the comma operator to further obscure where the data ends up. For example,</p>
<ul>
<li><code>12[f]=4[++c]&gt;&gt;k;</code> was incorporated into <code>w[0]*=6[f];</code> to yield <code>w[0]*=(12[f]=4[++c]&gt;&gt;k,6[f]);</code></li>
<li><code>w[15]=w[k]=e[12[f]]; w[11]=w[10]=e[1];</code> becomes <code>w[11]=(w[15]=w[k]=e[12[f]],w[10]=e[1]);</code></li>
</ul>
<p>A few other miscellaneous obfuscations have also been done:</p>
<ul>
<li><code>while(++f[15]&lt;12);</code> is used instead of <code>f[15]=12;</code></li>
<li><code>for(s=14[f]=0;s&lt;f[13];s++)</code> is used instead of <code>f[14]=0; for(s=0;s&lt;f[13];s++)</code></li>
<li>The line that contains <code>printf("Hello, world!");</code> is mostly commented out.</li>
</ul>
<hr />
<!--
(c) Copyright 1984-2019, [Leo Broukhis, Simon Cooper, Landon Curt Noll][judges] - All rights reserved
This work is licensed under a [Creative Commons Attribution-ShareAlike 3.0 Unported License][cc].
[judges]: http://www.ioccc.org/judges.html
[cc]: http://creativecommons.org/licenses/by-sa/3.0/
-->
<TABLE><TR>
<TD><a rel="license" href="https://creativecommons.org/licenses/by-sa/3.0/"><img alt="Creative Commons License" style="border-width:0" src="/png/by-sa-3.0-88x31.png" /></a></TD>
<TD><P>&copy; Copyright 1984-2019,
<A HREF="/judges.html">Leo Broukhis, Simon Cooper, Landon Curt Noll</A>
- All rights reserved<BR>
This work is licensed under a <a rel="license" href="https://creativecommons.org/licenses/by-sa/3.0/">Creative Commons Attribution-ShareAlike 3.0 Unported License</a>.</P></TD>
<TD>&nbsp;<!--<a href="https://validator.w3.org/check?uri=referer"><img src="https://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01 Transitional" height="31" width="88"></a>--></TD>
</TR></TABLE>
</body>
</html>
2019/giles/hint.text
+149
View File
@@ -0,0 +1,149 @@
# 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](https://www.youtube.com/watch?v=B7xai5u_tnk). The track was published under a free license.
This program has also been successfully compiled on Windows, with both the [Tiny C Compiler](https://bellard.org/tcc/) 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]]]]]
* `input`: The path to the input file. Required.
* `output`: The path to the output file. Optional, defaults to `out.wav`.
* `size`: The perceived size of the room, i.e. the approximate amount of time taken for the echo to fade away. Optional, default 1.6 seconds.
* `dry`: The amount of unprocessed signal ("dry" in audio terminology) to add to the output. Optional, default 0.3 or 30%.
* `wet`: The amount of processed ("wet") signal to add to the output. Optional, default 0.5 or 50%.
* `damping`: The amount by which high frequencies are damped out as the echo continues. This models the tendency for higher frequencies to be absorbed more than lower ones. Increasing this value causes the echo to be less "harsh" and more "muffled". Optional, default 0.06 or 6%.
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:
* Read and validate command-line arguments.
* Read and validate the header portion of the input file, and print some errors if that fails.
* Write a modified form of that header into the output file.
* Print the parameters read from the command-line arguments, in a human-readable format.
* Dynamically allocate some arrays of floating-point numbers, to be used later, with lengths based on the `size` parameter
* Read 16-bit audio samples from the input file, converting them to floating-point.
* For each audio sample, do a weird combination of addition, subtraction, and multiplication by constants, using the previously-allocated arrays to store results between iterations. Write the resulting audio samples to the output file, converting them back to 16-bit integers.
* Close all of the file handles and free the memory.
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.
`#define`s are used to abbreviate the code, which has a side effect of making it very slightly harder to read.
* `k` is just a general-purpose replacement for 16.
* `i` is the number of delay-lines to allocate and use (currently 24).
* `q` is an abbreviation for multiplying two elements of `w[]` together.
* `u()` is used to display percentages with proper rounding.
* `j()` imposes an upper limit on a floating-point value, and then negates it. This operation is used eight times.
* `D()` abbreviates a call to `setvbuf`, used to speed up file I/O.
* `l()` is used to clip audio samples to the acceptable range, and convert them to 16-bit integers for output.
* `g()` handles errors.
* `C()` contains the bulk of the signal-processing code, as well as a preprocessor obfuscation trick: If you were to read the body of the macro out of context, it will appear to have multiple mismatched square brackets, since `[` occurs more than `]`. However, this macro is always invoked with arguments such as `C(v],+10)` which contain an unmatched `]` character. When the macro is used in this manner, the extra `[`s in the macro's body are matched with the `]`s added through the first argument.
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:
* the input parameters (`w[0]` to `w[3]`)
* various constants needed for the reverb algorithm (`w[4]` to `w[9]`)
* temporary storage of floating-point audio samples (`w[10]` to `w[20]`)
`int32_t f[]` is even more multi-purpose. It contains:
* the header of the input file (`f[0]` to `f[11]`)
* the number of channels in the input file (`f[12]`)
* the number of samples of output to generate (`f[13]`)
* an end-of-file flag (`f[14]`)
* a variable that I forgot the exact purpose of (`f[15]`)
* indices into the circular buffers where audio samples should be inserted (`f[16]` to `f[39]`)
* indices where audio samples should be read out (`f[40]` to `f[63]`)
* lengths of the buffers (`f[64]` to `f[87]`)
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:
* `X[1]` -> `1[X]`
* `f[14]` -> `10[f+4]`
* `X[0]` -> `*X`
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,
* `12[f]=4[++c]>>k;` was incorporated into `w[0]*=6[f];` to yield `w[0]*=(12[f]=4[++c]>>k,6[f]);`
* `w[15]=w[k]=e[12[f]]; w[11]=w[10]=e[1];` becomes `w[11]=(w[15]=w[k]=e[12[f]],w[10]=e[1]);`
A few other miscellaneous obfuscations have also been done:
* `while(++f[15]<12);` is used instead of `f[15]=12;`
* `for(s=14[f]=0;s<f[13];s++)` is used instead of `f[14]=0; for(s=0;s<f[13];s++)`
* The line that contains `printf("Hello, world!");` is mostly commented out.
--------------------------------------------------------------------------------
<!--
(c) Copyright 1984-2019, [Leo Broukhis, Simon Cooper, Landon Curt Noll][judges] - All rights reserved
This work is licensed under a [Creative Commons Attribution-ShareAlike 3.0 Unported License][cc].
[judges]: http://www.ioccc.org/judges.html
[cc]: http://creativecommons.org/licenses/by-sa/3.0/
-->
2019/giles/prog.c
+44
View File
@@ -0,0 +1,44 @@
#include <stdint.h>
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#define k 16
#define i 24
#define q(a,b)(w[a]*w[b])
#define u(u)(int)((u[w]>0?1:-1)*.5f+100*u[w])
#define j(j,J)w[j]=w[j]>J?-(J):-w[j];
#define D(D)setvbuf(D,0,_IOFBF,a+1);
#define l(l)(K)(l>a?a:l>-a?l:-a)
#define g(g){fprintf(stderr,"%s\n",g);return 1;}
typedef int32_t I;
typedef int16_t K;
#define C(A,B) w[2 B]=t[ A[d[A];w[3 B]=w[1 B]+q(4 ,2 B);w[4 B]=w[2 B]-q(3 \
B,4);z[A*=w[3];z[A+= q(3 B,9);t[A[f[k+A]=z[A;k[f+ A=d[A++;if(d[A>=d[i+A)d[A
FILE*n=0,*h=0;float*t[i] ;void m(){if(n)fclose(n) ;if(h)fclose(h);for(I s=0
;s<i;s++)if(s[t])free(s[ t]);}int main(int A,char **b){I*S=(I*)"V@WDfcvcen"
"w#vf\4sg\5Gdb&ohwrs'na" "dm\11`g'}k|\12d~\x7f%{" "mz\14Nlc*z.a~ja/`ed`ee1"
"wx~w\22Erev3r}xq5x`fb6" "ts7&!7zqlk5(4+:yr{uu~w" "o2\34Otgx'>;)0,y\25[RY"
"\0MHY\33\4\26F\7\7)tFW" "\4IM\\\37\0\21A\3\3,bF" "JWNFO\22\15\35M\14\14 *"
"**",a=65535,f[3*i+k],O[ 42],*o =O,*c=f+1,*d=f +i +k,s,v;char*y; float z[i]
,X[i],w[21]={1.60f,.30f, 0.5f,.06f,.77f,.965926f, .258819f,.64731f,.9f};for
(s=0;s<5;s++)if(A>s+3){s [w]=strtod(b[s+3],&y);w[ s]/=*y==37?100:/*reverb!!
v[3]=2<<c[q+k+3];s=3+k+y printf("Hello, world!"); ;w[4]=(w+3)[k-1];)q=3*/1;
} for(s=0;s<42;s++) s[O] =S[s]^16843009*(s+1);y=( char*)o+12;j(1,1)h=fopen(
1<A?3[b-2]:y+5+k,y);if(! h)g(y+6)j(3,1)atexit(m); j(2,1)D(h)if(!fread(f,44,
1,h))g(y+6)j(1,0)if(*++c !=*o++||2[--c]!=1[o]||8[ c--]!=*o)g(y+6) w[0]*=(12
[f]=4[++c]>>k,6[f]);j(0, 6e5f)j(0,-4e3f)j(2, 0)f[ 13]=(I)*w+f[10]/(2*12[f])
;K*e=(K*)(f+ 10);j(3,1)w [9]=3[w]<0?1+3[w]:1-w[3] ;if( 3<=f[12]||(4[c++]&a)
!=1|| 6[c--]>>k!=k) g(y+ 59)7[c]=k/2*(4[c]=5+4*(a >>=1))-i+20;c[6]=2*c[6]/f
[12];f[1]=20+(10[f]=f[13 ]<<2)+k;n=fopen(A>2?1[b+ 1]:y+28,y+3);if(!n)g(y+36
)D(n)fwrite(f,28+k,1,n); printf(y+99,w[0]/6[f],u( 1),u(2),u(3));*X=(*w/=k);
1[X]=q(0,8);for(s=0;s<i; s++){if(s>1)s[X]=X[s-2]* 7[w];s[d+i]=(I)s[X];s[z]=
(s[d]=0);s[f+k]=1;if(s[X ]>99)f[k-1]=(s-1)|1;s[t] =calloc(sizeof(float),s[d
+i]);}while(++f[15]<12); for(s= 14[f]=0;s<f[13];s ++){if(f[14]||(10[f+4] =!
fread(e+1,2*f[12],1,h))) e[f[12]=1]=0;w[11]=(w[15 ]=w[k]=e[12[f]],w[10]=e[1
]);for(v=0; v<i;v+=2){w[ 14]=w[11];w[19]=w[k];if( v<f[15]){C(v],+10)=0;C(v+
1],+15)=0;}11[w]=q(5,14) -q(6,19);w[k]=q(6,14)+q( 5,19);}w[k]*=w[2];w[11]*=
w[2];w[11]+=q(10,1);w[k] +=q(15,1);w[20]=w[11];1[ e]=l(20[w]);2[e]=l(k[w]);
fwrite(e+1,4,1,n);}}//=w +=q(32];f[1]=36+(10[f&y) ;w[s]/=*y==37?1;59)7[c]=k