Babak Fakhamzadeh •

Excellent article, Alastair. I added a link to your piece in the comments of Janette’s listing for this work:

Shadows and substance – a walk in Harridge Wood

Sorry for the late response, Emma. It appears I was expecting to be sent a message when someone posts to the forum :/

But, even worse, I don’t really have an answer for you. Did you take a look at the pieces in our library?

https://walklistencreate.org/walkingpiece/

Thanks Ralph,

As you can see, our forum isn’t (yet?) too heavily used 🙁

It also pays to keep an eye on the event page, and the comments section, there:

A leap into the sonic future: Taking stock of the possibilities of locative audio for drama – and drama for locative audio

It seems to me there are a few strands of intent that are intertwined, here.

A standard should be broad enough, but also has to recognise it is unlikely to cover all instances and all eventualities. A standard that allows for everything is not likely to be a standard, meaning we would have no choice but to make abstractions and set limits.

A format that has a broader application than existing formats, and is more widely adopted then existing formats is beneficial to everyone involved.

It needs to be clear what the applications and limitations are for any format that we suggest.

To understand the potential challenges and limitations, we need to understand the variety of works we might want to include in being able to be described through this format.
Without being too abstract, can we think of examples of works, and what exactly sets them apart functionally, that we should consider to be able to be described through this standard?

I’ll start.

• Pretty much all ‘tours’ in izi.travel (or rather, the ones I’ve tried) are quite conventional audio guides. That is, audio is connected to geometric shapes that are defined in a geospatial environment (that is, circles or other shapes on the surface of the earth).

• It’s my impression that the works available through Soundtrails are, effectively, functionally, similar to izi.travel; audio/media connected to geometric shapes on the surface of the earth.

Josh, I’m not familiar with Janet Cardiff. Her website appears offline. I just checked the description of a work of hers, here:

https://web.archive.org/web/20051124075037/http://hirshhorn.si.edu/exhibitions/description.asp?Type=&ID=20

It seems to me this particular piece is, really, just one audio file.

What about Echoes? What about other, similar, tools? Do some include a kind of data that goes beyond media connected to geospatial information?

If requiring archival before a standard, lack of structural resources might prevent moving forward. Yes, a PhD study on this and the general concept of a standard, would be great, but, who can wait four years? And who would pay for that? Half the current apps/platforms operating in this space could be effectively dead in four years.

Involving multiple potential stakeholders is a good and important move forward. But, getting them on board would see a larger chance of success if we are able to agree on a unified and clear message, first. Inviting more people can result in more disagreement and a real risk of discussions and resolutions never leaving the starting gate.
If we do not start this discussion with a certain level of agreement, and no funding, we might not get anywhere.

I’ll let @hamish-sewell answer for himself on his intentions, but it seems to me that the obvious objective, here, is interoperability. If there is a standard, any platform can convert from and to that standard, and vice versa. So, @joshkopecek, if we agree on the standard, you can create a converter for .echoes to .olm, and @kris can create a converter for .olm to .stx.
But, this needs no explanation, right? We are all clear on this.
It’s just that, at this point, it seems to me that @hamish-sewell and @kris are in a position where, whatever the standard ends up being, Soundtrails actually can use that standard natively, without requiring an additional translation/conversion layer.
So, perhaps, for the sake of clarity, perhaps we should talk about .olm files as the standard, as opposed to .stx files, to clearly distinguish between the standard, and the format used by Soundtrails, even though Soundtrails might end up choosing to use the standard as their format.

I do think that creating a standard, without also necessitating the existence of a perpetual storage medium, is a worthwhile cause. Defining a standard is a much more important step than facilitating another free storage platform, which would have its own unique challenges, plenty of which would be completely unrelated to facilitating an open standard for locative media.
That’s not to say we can not envision and/or plan for providing a kind of storage facility for media that’s part of the instances of .olm.

Yes, @joshkopecek, approaching the internet archive is a great idea. In fact, it turns out that they already host audio, for free.
I just uploaded this, and it seems to work fine:

[audio src="https://ia601506.us.archive.org/3/items/a-test-recording-from-carapicuiba/mytest.m4a" /]

(Note, I marked it as ‘test’, meaning it should be automatically deleted after 30 days.)

They also appear to host video, but I did not test this.

So, this means that it appears we have a working solution for perpetually storing audio. Or, rather, as perpetual as it reasonably can get.

To go back to @joshkopecek’s list of points:

1. I’m not so sure we all agree on that we need to facilitate archiving works in their entirety. But, with Internet Archive hosting audio and video, we (or, the user) can, at no extra cost. Specifically, then, WLC could be a repository of .olm files, with linked media hosted on the Internet Archive.
   This could, at some point in the future, and with meaningful financial support, be changed to storing all data at WLC.
2. In the sense that the work is not accessible, if the media is available, then, yes, audio is one of the two types of essential components of .olm works. However, a standard can, and does, exist, without the need of linked/indexed files existing.
3. Yes, the format must be plain text.

Yes, WLC could host files. But, even at small individual volumes, we’ll need a budget. Our budget, so far, has been 0.
But, this opens up a completely different Pandora’s box; we’d be operating in a similar space as, say, Soundcloud, which struggles to survive. And that’s not considering ‘heavier’ media files like video.

In the mean time, WLC-based file hosting would not be used by users creating a soundwalk if they are not aware of WLC, meaning that WLC-based file hosting can only solve the problem that Josh mentions, for some.

I can be convinced otherwise, but I’m not sure that the benefits of offering ‘our’ own file hosting will not outweigh the benefits.

That said, I can also see a possibility where we’d offer a relatively small amount of storage space for the files, perhaps only a particular series of types of files, and these files only, that referenced in the soundwalk.

@Hamish, one more thing about the signatures: It’s possible I was not fully understanding your underlying thoughts on the purpose and meaning of them. Before we fully dismiss them, if we dismiss them, are you able to elaborate on how you saw their purpose a bit more?

Ah, sorry about misattributing the source of the line on the signature.

@Hamish: If you’re questioning whether we should consider not using plaintext, I’m very strongly against not using plaintext. Plaintext is the format that can always be read by anything.

@Hamish, @Josh: Yes, WLC, or any centralised repository, could function as a kind of issuing authority for unique signatures, but this can’t really be a requirement as part of the standard, as this prevents independent portability.
In addition, the purpose of this signature would need to be defined, and I’m not yet clear on what its purpose is.

In short, it then seems to me that the idea of this signature should be dropped.

On rights; it makes sense to allow rights to be set for each referenced file, individually, as well as for the piece as a whole.

On use cases: More clearly defined use cases are great to have.