Canopus ADVC110 Video Input Failure

iSight Camera Glitch

How To: Upscale a 1x1 Pixel Video to Full HD for Glitch Visuals in Resolume

Macro Lens + Pixel Sorting

16x9gifs Updated

http://16x9gifs.tumblr.com/

100 Iterations of H264 Compression

Small Dimensions of Videos and Subsequent Codec Glitches

A colour sequence was generated.

This colour sequence was rendered as video files of the following dimensions:
- 1 x 1 pixel
- 1 x 2 pixels
- 1 x 3 pixels
- 2 x 1 pixels
- 2 x 2 pixels
- 2 x 3 pixels
- 3 x 1 pixels
- 3 x 2 pixels
- 3 x 3 pixels

Each of these files was then upscaled to 1080p using four codecs.

Here are some highlights:

Upscaling a 1x1Pixel Video to 1080p Using 15 Codecs / Bitrates

I made a video that was had the smallest dimensions possible (1 pixel across, 1 pixel high).

Playback of this single-pixel video was extremely varied across media players.

This video was then upscaled to 1080p at various bitrates using different codecs.


Some stills from the outcome: 

Sausage Fattener VST as Graphic Effect

Before being fattened: 

After the fattening: 

Data Bending a Blank JPG Document

Data Bending a DXV File

Single Sample Point Music: Ableton Live As Medium and Process

Tonight, I've been writing music that uses the shortest sample possible - that is, a waveform that consists of only a single sample point. Not a sine wave, not a two-sample squarewave, but a single sample point on a waveform - i.e. a DC offset value, silence, as close to nothingness as one can have whilst still having something.

I've been fascinated for a long time with using minimal source material, and this is simply an extension of this as process.

There is an interesting side effect of using a "silent" sample that contains almost no information or material as source in Ableton Live. Process and medium are intertwined, and Ableton Live no longer behaves entirely rational; delay lines fail unexpectedly, the Simpler instrument no longer "pitch shifts" what little content can be heard from the sample and unexpected volume changes occur.

Anatomy of Mass JPG Killer

Anatomy of this patch: http://little-scale.blogspot.com.au/2013/02/controlle-corruption-mass-jpg-killer.html

Rosa Menkman is Speaking in Adelaide on June 13th

The Dutch artist and theorist Rosa Menkman will be presenting next week in Adelaide.

--- WHEN ---
5PM ++, Thursday, 13 June


--- WHERE ---
EMU Computer Suite, Room 4.05,
Schulz Building, University of Adelaide
North Terrace Campus


--- ROSA MENKMAN ---
rosa-menkman.blogspot.com

Every technology possesses its own inherent accidents. Rosa Menkman focuses on visual artifacts created by accidents in both analogue and digital media. The visuals she makes are the result of glitches, compressions, feedback and other forms of noise. Although many people perceive these accidents as negative experiences, Menkman emphasizes their positive consequences.

By combining both her practical as well as her academic background, Menkman merges her abstract pieces within a grand theory of artifacts (a glitch studies). Besides the creation of a formal "Vernacular of File Formats", within her static work, she also creates work in her Acousmatic Videoscapes. In these Videoscapes she strives to connect both sound and video artifacts conceptually, technically and sometimes narratively.

In 2011 Rosa wrote the Glitch Moment/um, a book on the exploitation and popularization of glitch artifacts (published by the Institute of Network Cultures), organized the GLI.TC/H festivals in both Chicago and Amsterdam and co-curated the Aesthetics symposium of Transmediale 2012. Besides this, Rosa Menkman is pursuing a PhD at Goldsmiths, London under the supervision of Matthew Fuller and Geert Lovink.

Controlled Corruption: Mass JPG Killer (Batch Glitch)

A simple glitch tool that lets you load a binary file (e.g. JPG), and then "glitch" it in a similar way eight times simultaneously.

An offset can be set, so as to bypass glitching the header component of a file. 

The "glitch" is a repeating byte (from 00 - FF) inserted at repeating period of X number of bytes.

This byte is a replacement byte i.e. no other bytes are moved, only the byte at X period length is replaced.

Thus, things can be explored, like:
• identical period length, different byte "corruption"
• identical byte value "corruption", different period length
• phase interactions and file structure using diferent period lengths
• and so on

Usage is simple:
• Click on "read" to read a binary file such as a JPG
• Set an offset in the master section (the upper row in line with read) - this will set the offset for all eight outputs
• Suggested offset is around 2000 bytes
• Set a data in the master section (the upper row in line with read) - this will set the data byte that is used for replacement i.e. inserted into as a "corruption" for all eight outputs
• Set a period in the master section (the upper row in line with read) - this will set the period length of the repeating glitch where the data is inserted into the file
• Suggested minimum period length is around 100 - 200 bytes
• You can also change these values individually for each eight outputs
• Once happy with the settings, hit the toggle next to read (the little square).
• The patch will generate eight text file windows with hex values in them.
• Copy and past the first one
• Open up Hexfiend
• Create a new Hexfiend file
• Paste into the hex area
• Save as a blah.jpg
• Repeat the last five steps for separate text file inputs and .JPG hex data outputs, saving each one to a new .JPG file
• Note that not all of the outputs will always result in readable files!
•Experiment :D


Download the Max patch here: http://milkcrate.com.au/_other/downloads/max_patches/BULK_JPG_GLITCHER.zip

Download hex fiend from over here: http://ridiculousfish.com/hexfiend/

The Max patch requires Max 6 or the free Max 6 runtime





You can see some example output here: http://www.little-scale.blogspot.com.au/2013/02/controlled-corruption-phase-base.html

More examples by Diode Milliampere:

Controlled Corruption: Phase-based Comparison of Dummy Data Replacement

Each image has been corrupted in an identical manner - after an offset of 0x800, the value 0xC5 replaced a byte every 200th, 201st, 202nd, 203rd, 204th and 205th byte within the body of the file, respectively (i.e. with the first file, every 200th byte was replaced with 0xC5; in the second, it was every 201st byte etc).

This resulted in similar glitches, whereby the input and glitch parameters were very precisely controlled.