Skip to main content

Sources, Citation, Studio

Texts to have read / listened to: Writer/Designer on “Working with Multimodal Assets and Sources” (Ball, Sheppard, Arola); Stuart Fowkes on field recording; Alison MacAdam on breathing life into audio scenes; and optionally some overviews of CC licenses and Fair Use.

Work to have achieved: a proposal for the audio narrative, posted to the issue queue

Plan for the day

  1. Final Repo Configurations: dealing with large files and sources you shouldn’t distribute (5-10 min)
  2. Composing Advice, Questions and Answers
  3. Key Concepts and Practical Takeaways from the Reading (10-20 min)
  4. Homework: preview (5 min)
  5. Studio time (40-50 min)

1. Final Repo Configurations: git-lfs and .gitignore

There are two features of your repository that we didn’t yet set up, but which should save you headaches as you get into the thick of the project:

1a. Git Large File Storage

Large file storage, or LFS, is a way to avoid counting large project files against your free storage. Essentially, it moves files you designate onto a separate server, and replaces them with a unique pointer to that file.

The setup is pretty simple, but it does require access to the command line.

Once you have the software, follow these steps to activate it:

  1. In either platform, open your repository in GitHub Desktop, then use the Repository menu to "Open in Terminal."
    screenshot of the Repository menu in GitHub Desktop
    You can find the "Open in Terminal" command under the Repository menu
  2. In the command line window that opens, type git lfs install and hit enter.
  3. Next, type git lfs track "*.aup3" and hit enter. (NB: You could also add other extensions, if you want, by swapping out the aup3 and doing it again.)
  4. Head back to GitHub Desktop, where you should see a new file called .gitattributes. Commit the change to that file, and that's it! Now anything that matches the filetype you selected in step 3 will be tracked using LFS.

1b. Ignoring files or folders

An even easier process will protect you from accidentally oversharing source files.

  1. In your repository, using Finder/Explorer, create a new folder and give it a name; for the sake of these instructions, I'll call it "sources".
  2. Now, in GitHub Desktop, I'm going to edit the Repository settings using the same menu as before.
    GitHub Desktop repository menu, highlighting the repository settings option
  3. In the dialog box that comes up, select "Ignored files," and then add a new line with the text sources/**.
    GitHub Desktop ignored files dialog box
  4. When you click Save, you'll see a new file called ".gitignore" in your list of changes. Commit the change, and now Git will ignore every file in that sources directory.
EXT: If you finish that and you're waiting for the rest of us, read through the next section of Q&As and pieces of advice.

2a. Composing advice, based on proposals

Lots of great ideas in those proposals. My small bits of broadly applicable advice:

This is My Life If you're doing a day-in-the-life or commute, the challenge is to make at least some of your sounds different from everyone else's: parts of a particular soundscape, not a generic one. Voiceover, even the little mutterings of a solitary person to themselves, may help; your choice of a soundtrack overlay might, as well.
Consider Getting it in Writing One benefit to drafting a project in prose is that your script doubles as a transcript – which improves both accessibility and discoverability. It also means you get clean version history as you revise your script. (One downside is that it's sometimes easier to do or say than it is to write.) Still: something to keep in the back of your mind, especially if you're working on something fictional.
Roll Tape On the flip side, if you're proposing something where you're not sure what you'll find, consider a journalistic approach: record more than you think you'll need; narrate what you're doing as you're doing it; then add a post-hoc voiceover that makes sense of (tells the story of) what you ultimately found.
Need to show time passing within a single setting? Try a crossfade If your proposal covers a long time – a full day, a full game, etc – you won't be able to represent it minute by minute. Instead, you'd normally want to jump from moment to moment with a sharp cut from one background track to another. But if you want to give a sense of time passing without changing where you are, one option is to fade out from the same background track back to itself, but later on, so there's still a sense of change within the sameness.

2b. FAQ / Q & A

And here are some great questions that came up in Perusall that I want to be sure to answer publicly:

I'm assuming that because repurposed assets are borrowed from other authors with their permission, they are not considered copyright?

Not exactly. Something being copyrighted does not automatically mean no one else can use it: it just means that the author gets to decide what permissions to grant. And in the US, as Ball et al note, "the moment an author 'fixes' an original idea into a text, he or she immediately has copyright over that text" – though they are permitted to transfer that right to others, e.g. to a publisher (154).

In the case of a work that's Creative Commons licensed, for example, the work is also still protected under the copyright of its creator(s), who can decide to change the license later; and all CC licenses (except for CC0) require derived works to cite the original creator. (This is the BY clause.) On the other hand, even copyrighted works are subject to fair-use doctrine, so reuse can't be restricted entirely.

Recently with the invention of neat AI systems like ChatGPT and Dall-E copyright has become a topic I'm more interested in. While ChatGPT and Dall-E generate text and image respectively, what happens when an AI generates music. Can someone copyright that as their own?

It's an open question, for now, and a tricky one! Part of the complication is how these AIs are trained: usually, by scraping and processing many thousands of previous creative works, including many that are under copyright. The question then becomes whether the resulting work is sufficiently transformative of the original art. If you do a targeted scrape of the collected works of Lin-Manuel Miranda and specifically ask the AI to produce music in the style of Lin-Manuel Miranda, that's probably too directly derivative. If you instead ask it to produce music in the style of Mozart, you might get something more new and strange – and therefore more defensible under fair use precedents. (Likewise, the more diverse the training set.)

Another part of the complication is the question of who counts as the "creator" of algorithmically generated works: the AI itself? the people who fed it training data? the people who wrote the algorithm? the people who passed the algorithm a prompt to generate from?

This is so new that it's only just starting to go through the courts, and it wouldn't be surprising for the courts to reach different conclusions that then have to be resolved higher up in the system. For those interested in reading more, think pieces abound. Here are a few I found just now:

What does "credibility" mean in the context of our soundscape projects, which are narrative rather than scholarly?

It's less a matter of accuracy, in this case, than of appropriateness and ethos more broadly: Does your use of the asset take genre expectations into account? Have you cited where it came from and your license for using it (which could be that it's a fair use, or that you created it), so listeners know you're being ethical in your sourcing?

Relatedly, if you're using CC-licensed material that includes an attribution (BY) clause, have you named your source in the derived project itself, i.e. in the audio? (Even if it's a "for full credits, go to this URL.") If you're using something with a sharealike (SA) clause, have you applied the same license to your own work? Do you have any incompatible SA licenses? Have any identifiable voices given their consent to being recorded, and have you documented that consent somewhere?

All of those actions help determine whether you seem trustworthy in your use of source material.

How does GitHub stack up to actual cloud storage services? Should we be mindful of how many commits of larger (non-text) files we make? This came in late enough that I don't have a full write-up, but two short answers: (1) this is why we need git-lfs, which I've already set up on the soundscape repository; (2) this is one reason to keep your full sources in a folder that you .gitignore
Screencast of submission process
Submitting a project preview: Save, Export, Commit, Push
Has anyone tried out any of the sites linked to from our plentiful Resources page? Any recommendations, warnings, or other advice for your classmates? Note that there are sections for both free/licensed sounds and music, and also (separately) for audio-unit-specific advice and examples.

3. Key Concepts and Practical Takeaways (10-20 min)

In a minute, I’ll ask you to group up and work through the questions below about the reading/listening from the last week, taking notes in the shared google doc (bit.ly/cdm2023spring-notes). Some questions you should be able to zip through quickly; others may require more discussion. (Heads up: even several of the True/False questions are more complicated than that binary implies! ;)

Let’s see what happens if we run with the groups from lesson 2, subject to roster changes since then:

  • Asher, Jackson, Lauren, Suchi
  • Diego, Janna, Jordan, Kellen
  • Mike, Ana, Betul, Christopher
  • Josie, Alex, Ariana, Michael
  • Ben A, Elio, Skylar, Taylor

3a. Using Sources

  1. True or false: if you can find it on the internet, you can use it in your project.
  2. True or false: the only sources you can use in this project are those you record yourself.
  3. True or false: if you record your own sources, you don’t have to cite them.
  4. True or false: if you use a source with a Creative Commons license, you don’t have to cite it.
  5. What’s the difference between fair use and Creative Commons?
  6. How would you define a “credible citation” in relation to the audio narratives you’ve proposed?
  7. Why do you think Ball, Sheppard, and Arola are so insistent about folder structure and file naming conventions?

3b. Recording Audio

  1. What’s one way to make sure you’re recording the sound you want to (and not, say, the loud bus passing by your conversation)?
  2. What do Fowkes and MacAdam consider tempting cliches of soundwriting, and how do they suggest getting past them?
  3. Would you (each of you, specifically, for this project) want to work from a written script? Why or why not?
  4. Would you (again, each of you in your group, today) want to incorporate human voices in your audio narratives? How or how much, and why (or why not)?

EXT: Bonus questions for the swift

  • Does my assignment of the Writer/Designer chapter fulfill the criteria of fair use? Consider all four major factors.

  • For each known asset in your project, add Rights information as per the “Touchpoint” on Writer/Designer page 160. (You’ll need to keep updating this, of course, especially as you determine what repurposed assets you really want to use.)

  • EXT: Read through the link at the top of Fowkes’ piece: Top 10 Simple Field Recording Tips. Any surprises that others in the class should know about?

As time allows, Let's talk through any questions or tensions that came up. I especially want to make sure we're all on the same page about those fuzzier "True/False" questions.

4. Homework preview (5 min)

Jump down

5. Studio time! (40-45 min)

Do whatever work you need to get something toward your project posted to your GitHub repository by Thursday: find audio sources you have permission to use, extract assets from them, record test voiceover with your phone or computer, start moving things around in Audacity, practice some more with GitHub Desktop (or command line git).

Warning: don't use the GitHub website for Audacity files! They quickly get too large for the site to handle. Instead, commit locally, then push, from GH Desktop (or the command line). Using Git-LFS should bypass that concern... but the website interface doesn't know how to do that!

The goal for now is to get a feel for how you work with audio, not to have a finished product. On Thursday, we’ll use your experience to refine our shared baseline criteria and brainstorm some aspirational goals.

To help with goal-setting and reflection (and, again, so I can figure out where I can be most helpful), please write a brief note in the shared doc about what you're planning to work on today; at the end of class, reply to your own note to say what you achieved and/or to set yourself a new goal for homework.

Call me in if you need help with Audacity, Git/GitHub, or determining the license on an audio source!

Homework for next time:

  • Look over the audio resources on the site, and dig into anything that seems like it would help you.
  • Work on your audio narratives, getting at least two sound assets in Audacity in conversation with each other. If you have time, do more!
  • Push a preview of your project to your GitHub repository. As per the assignment prompt, this should include:
    • A layered Audacity project file (.aup3), showing the arrangement of your sounds so far (need not be a complete soundscape or narrative yet).
    • At least one static screenshot (.png or .jpg) of your Audacity file in progress. (You'll use this in your final reflection, for comparison later to subsequent drafts). Note that link: you shouldn't need your camera for this!
    • A plain text (.txt) or markdown (.md) file, explaining in at least 300 words what you're showing us in this preview. Feel free also to ask questions or lay out next steps for yourself!
    • An updated list of assets (either directly in README.md or in a separate assets.md / credits.md file), indicating which the files you've actually recorded or otherwise obtained. Add source documentation for any outside sources – along with your permission to use them (e.g. licenses, fair use; see Writer/Designer p. 160-165). Remember: thanks to version control, you don't need to rename this file. :¬)
    • Finally, export a playable mp3 file, both as a snapshot and just in case something goes awry with your Audacity project file.

Jump back to studio instructions