Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[methylatedspirit]

These are some writeups I made about databending, or rather, new techniques that I haven't seen anyone publish yet. It's all posted on GitHub, which probably isn't the best way to do it, but I just wanted to get the info out there. This is pretty much all I know for now.

(Table of Contents)

Databending with Audacity: What I do Differently/Required Reading
|
--------> Addendum: What happens if you use different audio encodings while importing?

Databending with Audacity: The Effect of Paulstretch on Planar RGB Images

Databending with Audacity: FFmpeg as an Intermediary for Images

Databending with FFmpeg: (Ab)using Lossy Audio Compression to Databend Images
|
--------> Addendum: Automated image to audio 'bending

Databending with FFmpeg: Misinterpreting Audio as Video for Fun and Profit

Of course, all I'm doing here is based on other people's work, and none of this would be possible without them. The ones I could remember were:

Databending using Audacity by Antonio Roberts
Databending using Audacity Effects by questionsomething (this one inspired the Paulstretch piece, and it's the same technique down to using planar RGB, actually)

[methylatedspirit]

Wrote and added a new guide, Databending with FFmpeg: (Ab)using Lossy Audio Compression to Databend Images.

[McGee]

I think it turned out not bad, good job. Thank you!

[EuchreJack]

You might get more interest if you start with a Basic Databending topic/post/whatever.  You know, so we actually have a slight idea what you're talking about.
Old man Jack doesn't even know what Databending is.

Looks like art maybe?  You could detail some of your favs, or work you've done that came out well.

[methylatedspirit]

You might get more interest if you start with a Basic Databending topic/post/whatever.  You know, so we actually have a slight idea what you're talking about.
Old man Jack doesn't even know what Databending is.

I suppose, but I'm extending the work of the people before me, Antonio Roberts and questionsomething (real name unknown). They are the 'basic databending', at least in the branch I specialize in. I don't think it's particularly right to duplicate the scope of something that's purely factual and are a matter of procedure rather than art. My take on the basics won't be substantially different from that of my predecessors, and it would be worse, actually.

That being said, should I still make a "Basic Databending" topic linking to those articles and more, while making it very clear that I don't own those articles? There's this wonderful post that contains pretty much every glitch art (databending being a subcategory) thing, but I think it suffers from front-loading everything into the reader's face at once. I suppose I could trim it down, while acknowledging that I'm basing it off someone else's work. Unfortunately, the site mod has tragically passed away, so it's impossible to ask permission.

Looks like art maybe?  You could detail some of your favs, or work you've done that came out well.

I suppose you could call it art, but I work from a technical perspective. Artistic merit means nothing to me, what matters to me is that there is a repeatable and consistent procedure that can yield some kind of useful result that others can make use of later on. I'd be happy if someone implemented my techniques as automated filters, I really would. It would make this stuff far more accessible. It'd mean you don't have to download all this odd software and do all these strange things with them just to do what I did.

I'm going on a tangent here, but if someone did that, I'd link to their filter near the top of the relevant article, provided it is under an open source license under the Open Source Initiative's definition. I've very recently put my articles under CC-BY so that I'm not scaring people off with the copyright-by-default thing that occurs in most jurisdictions, mine included. Do what you want (with attribution), but I still retain the right to promote the things that I like.

I don't do art. I don't understand what makes any particular piece any better or worse than another. I can't even tell what's good and what's not. I leave others to do that, since that's not my specialty. I suppose you could call me a scientist.

[EuchreJack]

Right, so you're an Engineer.

It might help to see what Databending can do.  Like, pre-1900s nobody would know what an Automobile was unless they saw one, because most people didn't own them back then, and they weren't well known.

[methylatedspirit]

Wrote and added an addendum to Required Reading, What happens if you use different audio encodings while importing?

Also, I should really write an index page and intro article or something. I'd like this series to be self-contained, and I do want to write basically an opinion piece on what databending means to me (and what it can do; thank you EuchreJack), because it is narrower than the standard definition. I'm thinking on whether to merge the intro and index pages together, or to split them.

[EuchreJack]

Well, you could create a topic "Intro to Databending", then link to it in this topic, and link back.  Or just throw everything into one topic.  Whatever makes the most sense to you, really.

Spoiler (click to show/hide)

When in doubt, do one and see.  You can always do the other one if it makes more sense later.  You could do both also.

[methylatedspirit]

I was already decided on putting whatever I write as an introduction, into this thread, at the top of the list. A second thread on here would be a bit messy, I think. Of course, now, I've already written the little index/table of contents for the "series" (I guess it's a series now?), so I'll write up the introduction to my sort of databending later on, since that's the only logical step after that.

[methylatedspirit]

Wrote a new guide, Databending with FFmpeg: Misinterpreting Audio as Video for Fun and Profit.

There are 2 things I'm worried about with this one: a) it might be too long to navigate comfortably, and b) dead links. Especially dead links and images, since I've decided to use GitHub itself as the only file and image host for this guide.

[EuchreJack]

To prevent dead linkage, you could copy/paste/etc the sources themselves, if they're not too long.  Your stuff, then an appendix of the stuff you're referring to.

[methylatedspirit]

Nah, I meant dead links to my own stuff. I'm experimenting with this GitHub feature where you can link to things in your repo by specifying a relative link, like so:

Code: [Select]

[Link text here](assets/foo/bar/baz.mp3)

or

Code: [Select]

![Image description](assets/foo/bar/baz.png)

Considering that I don't write my first drafts on GitHub itself, I had to basically write blind, just noting down the names and location of my stuff as I went along, and hoping that I transferred them correctly to the repository. I also didn't plan out the repo structure in advance, so it's a bit of a mess.

[EuchreJack]

Wow, that is rough.

[methylatedspirit]

I mean, I had to link to audio files in this one, so I'd much prefer to reduce the number of dependencies, y'know? Like, if I used Google Drive links, now I'm dependent on both GitHub and Google Drive. If Google decides to block downloads (which does happen if there are too many at once), there goes half my article; those downloads are me trying to be accessible, so it really is half the article to me.

At least if I hosted everything on GitHub, I won't end up with a situation where my article is up, but my downloads are disabled. There's better ways to do it, I admit. But it works, I think. Just not sure how well.

[EuchreJack]

At some point you might want to throw up a Patron page or something.  See if anyone is interested in funding your research, or digitally purchasing your finest works.  Seems strange, but is apparently "a thing".  Good luck!