Sustainability

Despite its prevalence in digital humanities scholarship past (Mahoney 1996; Mahoney 2008; Rothenberg 1998) and present alike (Tucker 2022; Barats et al. 2020; Goddard and Seeman 2019), sustainability remains a difficult concept to articulate (Edmond and Morselli 2020). Commonly, sustainability is discussed in four overarching aspects: technological, financial, environmental, and human (Tucker 2022). Other discussions around sustainability—particularly as they relate to the practical development of DH projects—concern themselves primarily with the preservation and maintenance of both the static and dynamic elements necessary for a project’s continued functionality and accessibility (The Endings Project Team n.d.). As this paper explores case studies in practical problem-solving related to sustainability and audio, we focus particularly on this latter definition, while recognizing that the intersectional nature of sustainability is present in our work just the same.

Although this is a potentially unassuming problem on the surface, researchers have expressed how finding a comprehensive and scalable approach to sustainable development is a “non-trivial problem” (Smithies et al. 2019, 2) or even “virtually impossible” (Green et al. 2017, 15). Projects without a predetermined preservation plan are frequently abandoned (Carlin 2018), and predetermining such a preservation plan beyond the scope of a handful of years can feel futile at best (Green et al. 2017). Among the many hurdles to digital sustainability are ever-shifting file standards (Fiadotau 2020; Schüller 2020), steep learning curves for software with no guarantee to its continued usefulness (Drucker 2021), and the ephemeral nature of servers, hyperlinks, interpretive hardware, and other dependencies that can disappear without notice (Edmond and Morselli 2020; Rothenberg 1998). When taken in tandem with more general concerns such as devising strategies to suitably end a project (Rockwell et al. 2014), navigating uncertain ownership and the lack of time (Miller and Taylor-Poleskey 2020), and working within the technical, institutional, and financial constraints of the research team (Drucker 2021), it’s understandable that sustainability is among the most pressing concerns to the digital humanists of today.

Important work has been accomplished in response to these challenges, particularly the Endings Project out of the University of Victoria (Carlin 2018). On their simple but effective website (The Endings Project Team n.d.), the Endings Project introduces the importance of sustainability in DH, outlines the principles to serve as guidelines in sustainable development, provides technical dos and don’ts to better serve these principles, and even presents a multitude of sustainable web projects to serve as case studies. Their work is practical, listing programming languages, software, and other tools the sustainable developer should and should not use. These recommendations push the developer towards static outputs over dynamic server-side dependencies, established standards over fashionable technologies, and local solutions over third-party libraries—sentiments echoed by many other digital humanists advocating for sustainability (Drucker 2021; Russell and Vinsel 2018; Smithies et al. 2019). Following these guidelines, digital projects become substantially more resilient to the test of time and the volatility of changing technologies. However, holes remain: Of the Endings Project’s dozen-plus example projects, only one contains video (FrancoToile n.d.) and zero present or preserve audio files. This begs the question: can a website that presents audio remain “Endings-compliant” (LEMDO n.d.)? And if so, how?

Minimal computing

While sustainability looks ahead to the longevity or end of a project, minimal computing is concerned with the beginnings, orienting itself around a problem or set of “constraints” (Risam and Bessette 2024; Risam and Gil 2022). At its simplest, minimal computing stresses that digital humanists ask themselves, “What do we need?” (Gil and Ortega 2016). This leads to further questions: “What do we have?”; “What must we prioritize?”; and “What are we willing to give up?” (Risam and Gil 2022). By asking these questions, digital humanities projects can be steered towards accessibility, participation, stewardship, equity, and sustainability (Wythoff 2022).

Another key difference is in the approach to tools. The discourse around sustainability has espoused the need to adhere to “industry standards,” in terms of encoding, formatting, and describing archival objects, in order to ensure a project’s long-term viability. This is especially true within larger, multi-institutional organizations, like the SpokenWeb Network, where cross-compatibility is integral to maintaining the ability to integrate collections and functionality across repositories (Drucker 2021). Where sustainable research is invested in universal, standards-based approaches, minimal computing is more concerned with “local,” case-by-case solutions. Minimal computing and sustainable computing have a shared interest in exploring open-source solutions, which can mean a return to the basic building blocks of web development, such as working with HTML, CSS, and JavaScript. That said, minimal computing has also been described as “software-agnostic” (Risam and Gil 2022), in the sense of a willingness to adapt approaches in order to suit the needs of a project. Where sustainable approaches are deeply invested in usability, especially across systems, minimal computing is more concerned with access, particularly as it applies to teams with limited resources or access to reliable, high-speed internet. Along these lines, minimal computing has also been imagined as a strategy for decolonizing research, in that it takes account of the diverse “ecologies of technology” and does not assume that researchers are operating within the same constraints or realities, whether in terms of bandwidth or “regimes of censorship” (Gil 2022; see also: LaPensee 2017; Gil and Ortega 2016). For that reason, there is a tension within minimal computing between the various cost benefits of implementing an approach to website development, like a static site generator like Jekyll, which is minimalist in some senses but not in others. For instance, static sites are generated on the client side, as opposed to server-side dynamic sites, and so have less of a computational load and are accessible in areas with low bandwidth. Because static sites are generated as flat, HTML files, they can also easily be archived and stored offline. CMS sites, by comparison, are often difficult to export or to transfer to a different system: Once you have built a WordPress site, you are, in a sense, “locked in” to that service. That said, there is a higher cost to building static sites, in terms of labour. As Quinn Dombrowski points out, learning how to work with a static site generator like Jekyll requires, at minimum, some skills with CSS, HTML, and Markdown, and if you are building the site from scratch or redesigning the front- or backend, you will also need some knowledge of the Command Line, Git version control, YAML files, and Liquid templating language (Dombrowski 2022; see also: Chan and Sayers 2022). That is to say, the workflows associated with minimal computing, such as Jekyll-based Wax or Ed, can be incredibly taxing to learn and use. If project members are more comfortable with a more user-friendly (if less sustainable) content management system like WordPress or Drupal, is it worthwhile to retrain the team to use a minimal computing-friendly option like a static site generator? Or, if a team has the resources to hire a programmer or a tech-savvy graduate research assistant in order to get the site up and running, how will the project be maintained after the programmer’s contract ends?

All of that is to say, while minimal computing methods frequently overlap with those of sustainable computing, there are key differences, especially in minimal computing’s concern with access and willingness to supersede the latter’s stricter software requirements. While many sustainable projects are minimal and vice versa, differing expectations around software and other tools can cause minimal projects to reach for unsustainable solutions and for sustainable projects to reach for complex solutions. This trade-off is further explored in our two case studies, which additionally confront the complexities and considerations that are specific to audio-based research projects.

Audio

Sound is not digital humanities’ forte. Author Kelly Galloway remarks on the resounding “silence of the digital humanities” (Galloway 2017, 59), noting the absence of sound in the majority of our work and research. This blind spot has been similarly addressed by a handful of other researchers (Müske 2010; Campanini 2014; Birdsall 2016; Birdsall and Tkaczyk 2019; Gillaspy 2023), who draw attention to the need to further explore the historical and cultural significance of audio both historically in the form of radio and literary archives (Shepperd 2018) and during the present day in the form of audiobooks (Cannon and Rubery 2020). However, in recent years, there has been growing interest in exploring the sonic dimensions of the field. In 2021, Digital Humanities Quarterly published “Special Issue on AudioVisual Data in DH,” in which editors challenged the dominant position of text and word culture in the field, suggesting a turn towards new media forms, including audio/aural forms like radio and podcasts. The issue showcased a number of new projects, tools, and methods that focus on working with audio data and literary audio archives. Of particular relevance to our own project was the multi-institutional Unlocking the Airwaves project, which focuses on public radio collections and likewise used a static site generator to build a minimal collections website (Sapienza et al. 2021). Other notable digital humanities minimal computing tools with applications for audiovisual projects are AVAnnotate, developed by the University of Texas at Austin and Brumfield Labs, and the University of Idaho’s Collections Builder. The creation of the ADHO Special Interest Group AudioVisual Material in Digital Humanities (AVinDH), born from the DH2014 conference, is a further indication that digital humanists are finally tuning in to sound. Given that this is an expanding area within the digital humanities, addressing the complexities of creating sustainable and minimal audiovisual DH projects is of particular relevance and urgency.

During our team’s development of the two case studies, we found that introducing sound into conversations around sustainability, web galleries, preservation, and minimal computing complicated things in various ways, particularly the following:

1. The logistical and technical demands that come with preserving audio can clash with simplicity and dependency-free objectives of sustainable, minimal web design.

2. Academic institutions tend to have their own hosting solutions for multimedia, which can muddy our goals of minimizing complexity and dependencies.

3. Established software and workflows in minimal computing, while well-equipped for images and text, lack the tools to present audio with the same ease and finesse.

4. The lack of existing audio-focused minimal computing projects meant that a significant amount of time needed to be spent brainstorming and iterating upon methods of presenting our audio.

5. Audio as a medium can require specialty knowledge beyond the knowhow of the vast majority of digital humanists, especially when attempting to meet accessibility requirements.

When it comes to audio’s technical strain on sustainable and minimal project design, the most prevalent culprits are related to advancements in how recordings are “saved, compressed, and played” (Gillaspy 2023, 3). With over a dozen common file formats from WAV to MP3 to OGG—each with their own advantages and disadvantages—it can be a challenge to even decide on what file format best suits a particular digital project. For instance, the raw and uncompressed WAV file is unequivocally demanded of archivists and researchers prioritizing long-term preservation and sustainability due to the unrecoverable loss of information that results from lossy compression (Schüller 2020). However, the sheer size of WAV files—with 1 GB of storage being eaten up by only 90 minutes of WAV files—means that the storage and bandwidth concerns of minimal computing projects can be put into jeopardy. Additionally, the longevity of audio players and their compatible file types are never a historical certainty, given the passing of the once-popular Flash Player, RealPlayer, and Shockwave Player alike (Gillaspy 2023; Schüller 2020; Fiadotau 2020).

Institutional repositories, often sought after as a solution to digital projects with excessive file storage requirements, have developed significantly over the past couple of decades (Sterman 2014; Westell 2006). Nonetheless, they are far from a perfect solution for storage needs; institutional repositories can fall victim to the same sustainability pitfalls of any other digital project (Nkiko et al. 2014), introduce additional dependencies and points of failure, and drastically reduce the mobility a project has in migrating platforms. Additionally, many institutional repositories are hostile to multimedia, providing no method to view or listen to a file without the user downloading it first. The University of Alberta’s traditional institutional repository, ERA (Education and Research Archive), is one such repository, requiring the user to download each piece of multimedia individually before engaging with its content. Unsatisfied with its limited functionality, a second institutional repository with increased multimedia support, a more welcoming user interface, and additional presentation capabilities was recently set up. Aviary is developed by the company AVPreserve (AVP) and was implemented at the University of Alberta, following many years where the library maintained an instance of the open-source Avalon project. Aviary is the repository used in both case studies, albeit slightly differently. Despite Aviary’s advantages, our team still struggled with reconciling its various complexities and complications with a minimal computing ethos.

When surveying the software recommended by the Endings team—such as Jekyll, Wax, and HTML/CSS—one can’t help but feel disappointed by the lack of substantial audio support. While minimal and sustainable visual galleries can take advantage of the additional tools and functionality designed for the viewing and handling of images in Wax, there are not comparable options for audio collections (AV-Annotate 2025 is a notable exception and exciting development for the future of audio discoverability and searchability). Basic HTML provides only the most basic functionality, offering a difficult-to-customize audio player with nothing more than simple playback and volume control. Making matters worse, only four file types are compatible for playback within HTML: WAV, FLAC, MP3, and OGG—with OGG files being confusingly incompatible with the popular Safari browser (W3Schools n.d.). Over the course of our two case studies, the team identified the unsuitability of Wax to audio-centric galleries and developed custom audio controls using basic HTML/CSS/JavaScript that greatly extended what is available by default.

Similar to the lack of audio-oriented software tools, there is a lack of existing audio-oriented minimal computing projects. The aforementioned example projects on the Endings site provide little inspiration or guidance for how to approach implementing and presenting audio on the web. The limited number of projects created with tools like AV-Annotate are highly relevant to some projects—primarily those focused on speech, such as SpokenWeb—but have little relevance to other forms of audio, such as the field recordings of the Work Life project. As such, the iteration and brainstorming process around how audio is presented and implemented is likely to require more time, labour, and experimentation to get right. Speaking to our experiences with Work Life, we were able to quickly narrow in on how we wanted to present and implement our images, looking to the wealth of existing projects to help inform our design and decision process. Without role models in how to present and implement field recordings, settling on an approach to the project’s field recordings proved much more difficult, requiring dozens of revisions.

Finally, the W3 Accessibility guidelines for web design specifically address audio in multiple places, encouraging developers to ask questions such as “Is the volume across all audio files consistent and at a comfortable level?”; “Is any dialogue present easily audible?”; and “Are playback controls easily accessible at all times?” (W3C 2023). Unfortunately, knowing how to address these questions can be deceptively complicated; peak levels (dB) and average loudness (LUFS) paint different pictures of when an audio file is and is not of the right volume, and cleaning up dialogue could involve anything from volume compression to de-noise, to complex equalization curves, to de-reverb. These complications have been especially prevalent while preparing the audio files for Work Life in Canada, due to the natural differences and spikes in volume across the workplace field recordings. With certain members of our team having significant experience with audio and music, later in this paper we explore how these technicalities can be addressed by a DH audience.

In summary, it is understandable why digital humanists hoping to preserve and present audio media may find themselves reaching for third-party plug-ins, external dependencies, and server-side software to make up for the lack of existing support.

Picking the right (and wrong) tools

With minimal computing, sustainability, and the importance of presentation front and centre, our team ended up using the popular static website generator Jekyll, with the Wax gallery extension, and hosted the site on GitHub Pages. Jekyll and Wax are both staples of digital humanities projects, with Jekyll outputting static HTML and CSS from simple markdown files, and Wax extending the capabilities of Jekyll for exhibition usage to include advanced image-viewing capabilities. These two technologies both satisfy the guidelines set forward by the Endings Project (the Endings website itself is built from Jekyll) and avoid external dependencies and services. As previously alluded to, however, Jekyll and its significant barrier to entry have come under scrutiny by some minimal computing researchers (Dombrowski 2022). In an instance of sustainability vs. minimal computing give-and-take, the stricter software requirements of sustainability can threaten the “minimal” in minimal computing. Making the call of whether or not Jekyll is right for one’s project should be informed not only by sustainability principles but also the technical skills and time available to the team. In our case, SpokenWeb’s lead programmer was well experienced in JavaScript and web development, making Jekyll a less daunting—though admittedly still difficult—means of development.

In contrast, Jekyll can help make the process of hosting a site more straightforward. This is due to GitHub Pages—which allows users to host websites out of a GitHub repository with only a couple of clicks—having built-in Jekyll integration. While the ability to easily host Jekyll-built sites via GitHub Pages is often underappreciated, some digital humanists have drawn attention to its advantages (Wikle et al. 2020). However, this approach does come with a couple of trade-offs. First, storage is limited to the storage of your GitHub repository, which for the free plan totals only 2 GB. Second, relying on GitHub fits the description of relying on a third-party dependency, thus introducing additional points of failure and retracting some of the project owners’ agency over how the site is hosted. In order to minimize these trade-offs, our team supplemented our use of GitHub with our institutional repository Aviary, the implementation of which is discussed in more detail in the next section.

Among the core tenets of minimal computing is to only use what one strictly requires (Risam and Gil 2022). In hindsight, did our team select the proper tools? Jekyll excels at quickly (initial set-up not included) and efficiently building out a website using layouts and templates, and “includes” objects that allow users to create and edit pages within the same design language as the rest of their site. Creating new blog posts, inserting a consistent header or sidebar, and other such acts of site-wide repetition and editing are made significantly easier than working with the raw HTML/CSS each time. This was a feature the team found very useful, as it allowed us to create new exhibition, collection, and artist pages in a consistent and efficient manner. Additionally, once the initial set-up is taken care of with the theme, layouts, and templates, people without prior technical knowledge in web design and HTML can still contribute to the content of the site thanks to Jekyll generating the site from simple markdown files, helpful for sustaining a project whose team members and their skills may vary (Miller and Taylor-Poleskey 2020; Drucker 2021). Wax, on the other hand, extends Jekyll’s capabilities for the image gallery experience. Additional capabilities for advanced image zoom and handling image-related metadata make Wax a popular choice for digital humanities projects of the gallery variety. However, while SpokenWeb shared aspirations of having a gallery-like presentation, our content was primarily audio recordings, not images. While Wax was integrated into the site from the very beginning, its features ended up adding very little to our project.

Unfortunately, with Wax built into the site, we had to deal with issues raised by Wax. Wax comes with its own Jekyll theme, a set of rules on how Jekyll will generate the HTML and CSS of the site. Given that our site was part of a larger whole, we required a design language that fit in with the national SpokenWeb network. Unfortunately, it turned out that editing or even deleting the existing Jekyll theme in order to conform to our needs was unexpectedly difficult. As a result of having overwritten and edited the existing Wax theme, four CSS and SCSS files compete with one another within our code repository, leading to significant headaches within the development team. As demonstration, Figure 1 is a screenshot of the finished SpokenWeb UAlberta homepage, while Figure 2 is a comparison against the Wax theme from which we—and other users of Wax—started. Our team is in agreement that if given the option to start from scratch, they would opt to not use Wax or any existing theme at all, instead building our own custom theme from the ground up. This isn’t to say that Wax should not be used—Wax still provides an effective and powerful toolset for creating image galleries. However, careful judgment should be exercised when selecting the tools and technology to be used in a minimal computing project so as not to end up committed to complications one doesn’t need. In our eagerness to use a popular minimal computing tool, we in fact went against the minimal computing ethos, burdening ourselves with an extra layer of complexity that added little value to our project.

Figure 1: A screenshot of the SpokenWeb UAlberta homepage.

Figure 2: A screenshot of the website for Wax.

Meeting storage requirements and navigating institutional repositories

Given our usage of the GitHub platform, our storage was limited to 2 GB. While traditional image- and text-focused sites have little issue fitting within this allotted amount of storage, audio and video eats away storage at an alarming rate. Our audio files sourced from the digitized tapes are in WAV format, an uncompressed file type. Due to their uncompressed nature, WAV files have a consistent size-to-length ratio, with the math working out to mean that roughly only 3 hours of 44100 Hz 16-bit audio (CD quality) would completely fill our now measly 2 GB of storage. With some of our individual files being as long as 90+ minutes and there being over 120 recordings, there was no ability to have the WAV files stored locally with the repository.

Our solution was to stream all audio files off an external server. While many hosting sites would have likely sufficed, we opted to use Aviary—the institutional repository platform. Admittedly, this decision is at odds with a sustainable minimal computing approach that cautions against external services and dependencies. If Aviary were to go down, so too would all our audio. Additionally, the process of embedding and streaming audio from Aviary was technically complex.

In response to these challenges and in an effort to reconcile sustainable practices with the demands of an audio gallery, the team’s usage of the Aviary platform was made to be significantly more than an out-of-sight, backend repository. Aviary stands out amongst institution repositories in that it allows for a significant degree of presentation customization and multimedia support. Figure 3 is a screenshot of the SpokenWeb UAlberta homepage on Aviary, complete with a project description, search functionality, and tabs to different pages of the collection. Additionally, rather than needing to download audio and video files before accessing their contents, Aviary allows users to playback multimedia content directly from their browser, even going so far as to add additional playback functionality. Figure 4 is a screenshot of a recording page, featuring chapter selection and skipping, in addition to basic audio controls. In effect, the team achieved a significant degree of redundancy with this dual-tiered approach to implementation. The SpokenWeb site calls audio from Aviary, but Aviary can stand on its own with its own metadata, project documentation, and fully featured audio playback. In theory we can also build other sites that draw on the same content, for example, a site for teachers of poetry. The SpokenWeb site is, if you will, a singular interpretative and instructional layer built in parallel with its institutional media archive. By treating Aviary as its own frontend rather than a subservient backend, the project is able to maintain a sustainable infrastructure while managing to find a home for its dozens of gigabytes of audio files.

Figure 3: A screenshot of the SpokenWeb UAlberta archive webpage hosted on Aviary.

Figure 4: A screenshot demonstrating the Aviary user interface.

Combating long-term complications with upfront labour

Predictably, introducing Aviary into our development was not without its complications. In order to stream audio from Aviary on the SpokenWeb site, a lengthy manifest ID must be passed to the audio player. This manifest ID—unique for each individual audio file—is hidden within a metadata file that is not only difficult to find, but difficult to even parse with the human eye. Not only would the time investment necessary for manual input be astronomical, but the possibility of needing to retrain rotating team members across the lifespan of the project poses a substantial sustainability risk. In response, the team’s most experienced programmer created a Python script that draws from the relevant manifest files on Aviary to automatically populate the site’s HTML with the necessary metadata. Upon updating the site with new audio, a team member needs only to run the Python script prior to deployment in order to stream the newly added files from Aviary. This was done not only for ease of use, but also to ensure that development on SpokenWeb is not unsustainably reliant on the technical skills of a small handful of people. While the set-up for such a pipeline requires significant upfront technical knowledge, it allows for those with and without technical knowhow alike to contribute to the ongoing growth of the project. Creating solutions that are transferable from team member to team member is an essential part of reconciling the complexities of multimedia projects with sustainable practices.

The final piece of complexity to solve came in the form of the site’s audio player. HTML’s default offerings for audio playback are limited not only in functionality, but in aesthetics. Consisting of only a pause/play button, a volume slider, and playhead controls, HTML’s audio player suffices for simple preservation purposes but fails to meet the standards of more gallery-like presentation. Moreover, a key part of Aviary’s toolset was not compatible with out-of-the-box HTML controls—that of chapter markers and chapter skipping. As seen in Figure 4, Aviary makes it possible to denote particular chapters in an audio file’s metadata and then select that chapter from an index. Keeping with our aims to avoid external libraries, we solved these functional and aesthetic shortcomings by developing our own audio player using JavaScript, HTML, and CSS. This task was once again demanding in upfront technical knowhow but resulted in significant increases in functionality and aesthetics at no additional cost in long-term sustainability. Figure 5 is a screenshot of a recording page on SpokenWeb UAlberta, featuring the audio player anchored at the bottom of the page with overhauled aesthetics, chapter navigation buttons, and a scrollable list of chapter markers. As discussed, decisions made regarding software solutions should be considerate to a teams’ unique capabilities, and we are not encouraging every team to develop their own multimedia solutions from the ground up. Instead, we hope our case studies provide insight into both the principles and practicalities that are involved in creating sustainable audio exhibits inline with minimal computing practice. Finally, all code written for SpokenWeb—including the custom audio player—is open source and can be accessed at the site’s GitHub repository (SpokenWeb UAlberta n.d.).

Figure 5: A screenshot from SpokenWeb UAlberta demonstrating how the team translated Aviary’s functionality to the site’s user interface.

Compression for the web

Addressing the last question first, it is necessary to determine if an audio file is uncompressed or has already gone through compression prior to handling. As previously mentioned, WAV is the uncompressed format most likely to be encountered, with AIFF also being popular. Recording devices, digitization devices, and audio software export features will virtually always default to WAV format unless specified otherwise. Whether they contain silence or a busy cityscape, WAV files have a consistent length-to-file-size ratio, barring occasional differences in sample rate or the number of channels. Applying this calculation to the 2-GB limit of GitHub, it is only possible to host around 3 hours of stereo WAV files, far lower than the requirements of either SpokenWeb or Work Life. For audio projects hosting WAV files, repositories such as Aviary are practically a necessity. However, lossy compression algorithms exist to significantly decrease audio file size, the most well-known of which is MP3. Unlike WAV, the file sizes of MP3s and all other compressed audio files interact with audio contents in a nonlinear fashion and can vary wildly (Brandenburg 1999), but on average, one can expect a compression ratio of roughly 8:1 to 11:1, while retaining the majority of the audio file’s perceivable quality. Figure 7 showcases the varying file sizes of a recording taken at one of Work Life’s featured workplaces as it is put through compression algorithms. Going from a 44100 Hz 16-bit WAV to a 128-kbps MP3, the result is a size reduction of roughly 91%. MP3 files also have the advantage of being universally compatible with all major web browsers (W3Schools n.d.), ensuring all users can access the site’s audio without compatibility issues. In the same way the MP3 file made mobile music listening and music streaming a mainstream experience (McCandless 1999), MP3 files can potentially enable developers of projects involving audio to host significantly more content locally than otherwise. Nonetheless, sometimes MP3 files still aren’t small enough to satisfy storage restraints, or to meet strict limitations on available bandwidth. In these situations, compressing WAV files with OGG Vorbis compression offers an alternative approach to minimize file size while retaining good audio quality (Gunawan et al. 2017). Most OGG Vorbis algorithms provide a simplified means of file quality control, which allows users to provide a value between 0 and 1 to specify the degree to which the file is compressed. Figure 7 compares how the original WAV file converted to a 0.5-quality OGG is 30% smaller in file size when compared to the MP3. Finally, it is worth discussing FLAC compression as an excellent alternative for projects that only need to save a small amount of storage space. Unlike MP3 and OGG, a FLAC file uses lossless compression, meaning they can be uncompressed without needing to approximate data that lossy compression makes irrecoverable (van Beurden and Weaver 2024). While this results in much larger files than lossy forms of compression, lossless compression strikes a balance between authenticity and file size. We noted a roughly 50% reduction in file size when compressing 44100 Hz sample-rate WAV files to 44100 Hz sample-rate FLAC files using a 16-bit encoding depth and the default data compression value in REAPER. While this was still far too large for our needs on SpokenWeb and Work Life in Canada, FLAC compression being lossless and compatible with all major web browsers makes it a great fit for projects that require a lesser degree of compression.

Several options are available to carry out audio file conversion. In addition to free online solutions for small conversion tasks, the author recommends the free and open-source Audacity (Audacity n.d.) and the generous free trial of REAPER (Cockos Incorporated n.d.). Both applications are full-fledged digital audio workstations (or DAWs) and are capable of batch exporting dozens or even hundreds of audio files at once in all manner of file formats. While specificities vary between DAWs and are better left to tutorials, mass importing WAV files into their own individual tracks and using an “export individual tracks as stems” option in the export menu will output all audio files individually with the selected conversion process applied to each of them.

Figure 7: A screenshot comparing the file size differences between a WAV, MP3, and OGG file.

Unfortunately, compressed audio files still have their problems. First, OGG files are confusingly incompatible with the popular Safari web browser (W3Schools n.d.), raising concerns over accessibility. Second, the means through which this compression and conversion process can be carried out in a fast, repeatable, and scalable way is not immediately apparent to those of us without prior experience working with audio. And most importantly, while the difference in audio quality is generally unnoticeable to the human ear, the process of MP3, OGG, and most other forms of compression are fundamentally lossy, resulting in a nonrecoverable omission of information (Schüller 2020). Those specialized in audio preservation have thus rightfully identified lossy audio compression as simultaneously “inappropriate” for archival purposes while being “indispensable” for dissemination over the internet (Schüller 2020). How then do digital humanists decide—on a project-by-project basis—which takes priority over the other? In what has become an all-too-familiar game of give-and-take, the Work Life team is attempting to reconcile these two halves not only with one another, but with principles of sustainability, minimal computing, and audio presentation.

When to compress: Compression, preservation, and minimal computing

While the “what” and “how” of audio file compression are relatively straightforward questions to tackle, the “when” is highly contextual to each individual project. Of essential consideration is the nature of the audio being presented and/or preserved. From musical recordings and radio talk-show archives to field recordings and digitizations of cultural performances, each should be carefully considered as having unique needs (Shepperd 2018). For example, lossy compression shrinks file size by manipulating psychoacoustics in order to reduce the accuracy of specific components less likely to be detected by the human ear (Jayant et al. 1993). Of course, digital audio analysis tools are not the human ear, meaning attempts at the scientific analysis of a compressed audio file are moot in comparison (Schüller 2020). Additionally, though lossy compression may attempt to achieve perceptual transparency, listeners will usually find themselves preferring the sound of a lossless audio file (Pras et al. 2009). The importance of audio quality, audio analysis, and audio file size all need to be weighed against one another in order to determine the best course of action for any given project.

When examining the context surrounding the Work Life project and its audio, three primary characteristics stand out. First, our vision for the site is that of a gallery, not just an archive. In other words, aesthetics, user experience, curation, and presentation are all key focal points of our development. Simply archiving the original files in pristine condition on a highly sustainable infrastructure is not enough to suit our goals. Second, a theme of temporality is prominent throughout the project, which carries over to its audio. The majority of interview subjects (referred to internally as “protagonists”) have been interviewed and photographed twice, with the gap in between often spanning over a decade. With the past and present photographs displayed prominently at the top of each protagonist’s page and the content of the interviews referencing both past and present, the passage of time is an essential facet of the gallery experience. The field recordings can similarly be interpreted as time capsules of each protagonist’s workplace. More so than theatrical recordings such as a musical performance, field recordings are inseparable from their recording date, as they document not just a soundscape, but a soundscape at a specific time and place in history. The sounds we hear are fleeting—as the years pass and the world changes, so too do the sounds around us (Schafer 1977). Third, many of Work Life’s protagonists share their stories from rural areas, reserves, and other historically disadvantaged areas that may not have access to the same blistering internet speeds that those of us in an academic setting take for granted. This raises important concerns around data sovereignty, accessibility, and decolonization: How can we ensure that all who are the subjects of the site’s content are able to access and engage with the gallery?

As such, the Work Life team felt that there were cases to be made in favour of both compressing and not compressing. The concerns around sovereignty and accessibility strongly advocated for lossy compressed audio files; the temporal nature and sound content of the field recordings suggested we should present and archive the original WAVs; and the gallery experience would benefit from both the accessibility afforded by smaller file sizes as well as the artistic and scientific integrity of the uncompressed files. This led to us settling on our dual-tiered approach, which hosts the original uncompressed files externally on Aviary and compressed MP3 versions locally on the GitHub repository. Upon loading an audio file, the site first checks for two things: “Is the Aviary server currently up and running?” and “Is the user’s internet connection fast and stable enough to stream uncompressed audio?” If the answer to both of these questions is yes, then audio is streamed from Aviary in the same way that it was for SpokenWeb. If the answer to either question is no, then the site falls back to using the significantly smaller MP3 files stored locally. While still enjoying the benefits of uncompressed audio, this solves the problem of all audio on the site wholly relying on an external site, while also addressing accessibility concerns over large file sizes.

How does this solution change the site’s relationships with minimal computing and sustainability? Work Life will benefit from increased sustainability due to removing its dependency on Aviary and increasing its redundancy, while also following minimal computing practice by hosting files within the repository and keeping bandwidth requirements at a minimum. After detailing the many dynamics of give-and-take that inevitably spring up when tackling minimal computing and sustainable web projects, it is a touch ironic that our solution to Work Life was to find a way to do both: compress and uncompress, to make minimal and sustainable. Ultimately, however, there is a hidden cost still being paid—upfront specialized labour. While making our project Endings-compliant has meant that the final product of the Work Life site should function supervision-free for years to come, the labour it has taken to get there is substantial. Our team is fortunate to have maintained the same core group of academics and research assistants across multiple years, as any turnover of core members would have resulted in a setback made all the more difficult due to the specialized and technical nature of our solutions. In a similar way to how Dombroski questions the “minimalism” behind the labour necessitated by minimal computing tools (Dombroski 2022), it is important to consider the sustainability of the labour necessary to produce sustainable products.

Authorial

Authorship in the byline is by magnitude of contribution. Author contributions, described using the NISO (National Information Standards Organization) CrediT taxonomy, are as follows:

Author names and initials:

Catherine Bevan (CB)

Chelsea Miya (CM)

Jesaya Tunggal (JT)

Geoffrey Rockwell (GR)

Sara Dorow (SD)

Authors are listed in descending order by significance of contribution. The corresponding author is CB.

Conceptualization: CB

Funding Acquisition: SD

Methodology: CB, CM

Project Administration: SD

Resources: CB, CM

Software: CB, CM

Supervision: GR

Writing – Original Draft: CB, JT

Writing – Review & Editing: CB, CM, GR

Editorial