A rather John Cage-ian anti-music piece although the only thing of interest but the way it was written I wasn't sure if the 4 GB limit "discovered" FAT32's limit or if it was a MP3 format issue that players simply couldn't handle files larger than 4 GB because they were 32 bit. Other than that, I can't really say that creating a project of 700 days of generated noise is very interesting from an art perspective, but I…
It could become even more art if it included a performance of playing this for 711 days, with someone changing the DVD to the next one every 3 days.
A terabyte of harsh noise, stored on 233 DVDs
11–20 of 43 posts
Re: A terabyte of harsh noise, stored on 233 DVDs
#12Earlier quoted context omitted.
It could become even more art if it included a performance of playing this for 711 days, with someone changing the DVD to the next one every 3 days.
There's a John Cage piece called "Organ^2/As Slow As Possible" that is currently being performed on a specially-made pipe organ in Germany. Note changes happen every few years and the piece will finish in 2640. https://en.wikipedia.org/wiki/As_Slow_as_Possible
Re: A terabyte of harsh noise, stored on 233 DVDs
#13Another data source for /dev/random?
Re: A terabyte of harsh noise, stored on 233 DVDs
#14Re: A terabyte of harsh noise, stored on 233 DVDs
#15 // basically no wimpy numbers - only fat ones
if (s > 0 & s -30000) {s = (short) (s - 30000);}
s is a Java 16-bit signed short initialized to a random value. His intent is apparently to modify s to generate sound samples in the ranges [-32768,-30000] and [30000,32767] to make the noise "harsh" (no samples close to 0). But because shorts wrap around the boundaries -32768 and 32767, most samples will in fact be in the range [5537,32767]. See for yourself: if s=5537, he adds 30000, s wraps to -29999, he subtracts 30000, s wraps again back to 5537. s will end up in the ranges [-32768,-30000], [0] and [5537,32767], making the noise less harsh than it should have been.Damn I would hate to have to re-burn 233 DVDs, or this set of 510(!) he produced later: http://www.jliat.com/HNW510/index.html
This type of bug, an integer overflow, is one of the many types of bugs I look for when I review source code as part of my job in info sec.
[1] http://jliat.com/HNW/HNW.java
Re: A terabyte of harsh noise, stored on 233 DVDs
#16If you're going to master an original work in a digital format, and it's going to be a terabyte of anything, why MP3 and not FLAC? Figure at a bitrate of 128 kbps, and a sample rate of 44.1 Khz, an MP3 1 million bytes in size usually clocks in at close to 1 minute of playback. With those statistics in mind, a ballpark figure of 2 years of noise is a reasonable estimate, and that's pretty close to the 711.5 days they…
Re: A terabyte of harsh noise, stored on 233 DVDs
#17Re: A terabyte of harsh noise, stored on 233 DVDs
#18Re: A terabyte of harsh noise, stored on 233 DVDs
#19Re: A terabyte of harsh noise, stored on 233 DVDs
#20If you're going to master an original work in a digital format, and it's going to be a terabyte of anything, why MP3 and not FLAC? Figure at a bitrate of 128 kbps, and a sample rate of 44.1 Khz, an MP3 1 million bytes in size usually clocks in at close to 1 minute of playback. With those statistics in mind, a ballpark figure of 2 years of noise is a reasonable estimate, and that's pretty close to the 711.5 days they…