Forum Replies Created
-
Posts
-
Questions and Answers from the Sounds from he Chase & Chalke workshop chat – we recommend you check our earlier posts that also have lots of Q&As from our previous “how to make sound walk” workshop
Q: Where to find Voice Memo on Iphone to use for recording audio
A: On iPhone voice memo is usually found in the ‘utilities’ folder – I ask Siri to open it!Q: source of Sound effects Effects SFX?
A: try “epidemic sound” for music and Sound FX – but there are many sources, just google or search on YoutubeQ: What was the editing software that was demonstrated?
A: https://www.audacityteam.orgQ: What is the url for Echoes?
A: https://www.echoes.xyzQ: Are you only able to upload walks on laptop/computer? It doesn’t seem to have the new walk option on the app on android?
A: Only on the computer if you are an Android userQ: With the echoes app is it possible to listen to recordings on a walk without begin in the area. E.g could I listen to recordings from a Poland walk in Australia?
A: Within the app but not on the web – but I will check on that with Echoes!Q: Within Echoes you can plot a possible online route and hear what the sound walk would sound like. How do you do that?
A: You can start by only making your walk ‘Private’ not public and there is also a Preview facility tooQ: what is the URL for Shorelines?
A: https://walklistencreate.org/wr_instance/shorelines/Q: Are the walks curated by Echoes? Can you delete it if wanted?
A: No Echoes doesn’t curate them – however, a user is offered walks close to where they are. And yes – you can delete your walks on Echoes. Echoes team are able to remove walks however this rarely happens and – as far as i know – only in extreme cases. you can create and manage any kind of walk from the website and Echoes team do not curate them. They are happy to give tech advice if needed, though.Q: where is the link to the Forums?
A: https://walklistencreate.org/forums/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:
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?
It’s possible to attach a range of licenses to work uploaded to the Internet Archive. But, all variations of Creative Commons.
I’m quite sure you can not put content behind a login; it would arguably defy the purpose of the Internet Archive.
Either way, I think this is sufficient for our purpose and needs, here; we’re looking for a place to store media in a way that reliably provides longevity of accessibility.
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:
(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:
- 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. - 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.
- Yes, the format must be plain text.
I think we’re discussing two things, here; the importance/need of a standard, and the importance/need of preserving media. These are related, but not the same.
Defining a standard stands apart from preserving media. So, we can talk about one as well as the other, without requiring one for the other.
Because long-term cost-free, or nearly cost-free, file hosting is a completely different beast altogether, I don’t think this needs to be part of the discussion on a standard for locative media.
That said, I’m also very keen to discuss options for providing long term cheap storage.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?
On how to reference media; it doesn’t seem ideal to allow for inclusion of files within the context of the standard as this quickly could see overall file size explode.
@josh: I’m not sure I follow your reference to a container format.
I’d say that, yes, it would be the author’s responsibility to find a place to host files. Though, I suppose, it could also be allowed for file references to not be URIs, but also be referenced as relative to the open standard file.
So, it seems we’re leaning towards ditching a signature, yes?
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.
