<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0">
<channel>
<title>Digital Preservation Q&amp;A - Recent questions tagged audio</title>
<link>https://qanda.digipres.org/tag/audio</link>
<description>Powered by Question2Answer</description>
<item>
<title>Are there accepted alternatives to WAVE for storing audio files larger than 4GB?</title>
<link>https://qanda.digipres.org/1123/there-accepted-alternatives-storing-audio-files-larger-than</link>
<description>&lt;p&gt;
	The total size of a WAVE file is defined by a 32 bit integer in its header. Depending on whether a developer interpreted the spec as a signed or unsigned integer, WAVE files have a maximum size of 2 or 4 GB. Using 24 bits @ 96 Hz to digitize audio creates about 2GB per hour with stereo. So audio preservation master WAVE files have a 2-hour duration limit. We have a number of audio media that exceed that duration, especially with formats like open reel audio that don't have a defined size limit.&lt;/p&gt;
&lt;p&gt;
	As far as I can tell, it is standard practice in the digitization community to save a 2+ hour audio stream as 2 or more WAVE files with 30 seconds of overlap to match up the streams. Here's an example being served by the American Archive of Public Broadcasting (&lt;a rel=&quot;nofollow&quot; href=&quot;http://americanarchive.org/catalog/cpb-aacip_28-gf0ms3kc4t&quot;&gt;http://americanarchive.org/catalog/cpb-aacip_28-gf0ms3kc4t&lt;/a&gt;).&lt;/p&gt;
&lt;p&gt;
	However, splitting up the audio stream is causing downstream preservation problems because I cannot find a simple way to encode the relationship between the preservation masters. The semantic relationships become even more complicated when edit masters are created that do not have the same relationship to each other as the preservation masters. Finally, the split files provide a disjointed performance of the original asset for our users.&lt;/p&gt;
&lt;p&gt;
	The easiest solution would be to use a format that can hold more than 4GB of data. There have been some attempts to extend WAVE with WAVE64 and RF64. There are also other audio formats such as FLAC. IASA even recommended creating multiple mono WAV files and saving them in a single TAR (&lt;a href=&quot;http://www.iasa-web.org/tc04/key-digital-principles&quot; rel=&quot;nofollow&quot;&gt;2.8.3&lt;/a&gt;). However, I haven't found documentation that any of these have been widely accepted. Is there a common strategy for creating 4GB+ audio files?&lt;/p&gt;</description>
<guid isPermaLink="true">https://qanda.digipres.org/1123/there-accepted-alternatives-storing-audio-files-larger-than</guid>
<pubDate>Thu, 23 Jun 2016 15:56:59 +0000</pubDate>
</item>
<item>
<title>Best method to record track playing order for ripped audio CDs</title>
<link>https://qanda.digipres.org/1082/best-method-record-track-playing-order-for-ripped-audio-cds</link>
<description>&lt;div id=&quot;preview&quot;&gt;
	&lt;p&gt;
		Although there’s quite a bit of info on the web on audio CD preservation, most of the resources I found tend to focus on the audio ripping process. However, when you rip a CD to a bunch of audio files, it’s important that the original playing order of the tracks is recorded somewhere. Of course you can (and should!) do this at the preservation metadata level, but for access you also want to have some mechanism that allows an end user to hear the individual tracks in their original playing order (e.g. in a multimedia player application). From the top of my head I can think of 2 general approaches to achieve this:&lt;/p&gt;
	&lt;ol&gt;
		&lt;li&gt;
			Record the playing order inside the audio files themselves, e.g. using “Track Number” tags that are embedded as &lt;a href=&quot;http://www.sno.phy.queensu.ca/%7Ephil/exiftool/TagNames/RIFF.html#Info&quot; rel=&quot;nofollow&quot;&gt;&lt;em&gt;RIFF Info&lt;/em&gt;&lt;/a&gt; or &lt;a href=&quot;https://en.wikipedia.org/wiki/ID3&quot; rel=&quot;nofollow&quot;&gt;&lt;em&gt;ID3&lt;/em&gt;&lt;/a&gt; tags.&lt;/li&gt;
		&lt;li&gt;
			Use a separate play list file. For this &lt;a href=&quot;https://en.wikipedia.org/wiki/Playlist#Types_of_playlist_files&quot; rel=&quot;nofollow&quot;&gt;several formats&lt;/a&gt; exist, such as &lt;a href=&quot;https://en.wikipedia.org/wiki/M3U&quot; rel=&quot;nofollow&quot;&gt;&lt;em&gt;M3U&lt;/em&gt;&lt;/a&gt; and &lt;a href=&quot;https://en.wikipedia.org/wiki/XML_Shareable_Playlist_Format&quot; rel=&quot;nofollow&quot;&gt;XSPF&lt;/a&gt;.&lt;/li&gt;
	&lt;/ol&gt;
	&lt;p&gt;
		The main problem I see is that all of the above methods are supported by some players (and not by others), but I have have some difficulty in judging which approach would ensure the most widespread support. This made me wonder if there are any recommended best practices for this? What are other people doing?&lt;/p&gt;
&lt;/div&gt;
&lt;p&gt;
	&amp;nbsp;&lt;/p&gt;</description>
<guid isPermaLink="true">https://qanda.digipres.org/1082/best-method-record-track-playing-order-for-ripped-audio-cds</guid>
<pubDate>Tue, 20 Oct 2015 13:52:30 +0000</pubDate>
</item>
</channel>
</rss>