Re: Truncating an audio file
Re: Truncating an audio file
- Subject: Re: Truncating an audio file
- From: Brian Willoughby <email@hidden>
- Date: Thu, 01 Aug 2013 16:27:09 -0700
I'm going to say that "experiment" is the worst advice possible. I've
seen far too many audio applications which create noise in their
output files by making amateur assumptions about file formats.
AIFF and WAV are not files with "headers." They are both based on a
"chunk" format, where the chunks can appear in any order, and at any
offset within the file. There are specific rules about editing
existing files, because some non-audio chunks may become invalid
after the audio data has been edited, especially when length is
changed. Most importantly, both AIFF and WAV have a total data length
value in the master chunk which must be updated after the audio data
chunk has been truncated. Obviously, the audio chunk also has a
length which must be updated.
I have seen audio applications show and play noise bursts at the end
of a recording because they assumed that nothing comes after the
audio chunk. This is not true. ID3 and other optional chunks can
appear in any order in an audio file, and thus you can never assume
that it's legal to truncate a file without interpreting the chunks
inside the file.
MP3 will probably react poorly if you truncate a frame in the middle
instead of on a boundary.
Sorry, but there isn't really a fast and easy solution here. You can
write your own parser for file formats, and suffer the pains of
creating support for every file format that your users want, or you
can suffer the long delay of copying a file to remove trailing
silence. Apart from that, the only option is to avoid storing the
silence in the original file in the first place!
Brian Willoughby
Sound Consulting
On Jul 31, 2013, at 22:17, Kevin Dixon wrote:
AIFF and WAV should also work perfectly, as they are flat files
(header, header, PCM), though you will have to close/truncate the
file, the open and update the header to have correct info about
duration, etc.
I think you will find you need to update the header of MP3 as well,
though "missing data", if it falls after a frame boundary, will
probably just generate a warning in a decoder--then again, 60
seconds of silence should compress pretty well-- you'll have to
update the header regardless if you want the length info to be right.
-Kevin
On Wed, Jul 31, 2013 at 10:06 PM, Jens Alfke <email@hidden>
wrote:
On Jul 31, 2013, at 12:34 PM, patrick machielse
<email@hidden> wrote:
In an application, I'm recording audio to file using the
ExtAudioFile API. After recording is finished, there may be the
need to chop off up to 60 seconds of audio from the end of the
file (which will be silence).
ExtAudioFile doesn't seem to have functions that would support
this type of operation.
It’s been a long time since I looked at the API; if it has a way
to get the byte offset corresponding to a particular timestamp,
you can then just pass that offset to the truncate() system call.
Whether this will actually work correctly depends on the file
format, though. It should work with MPEG-type formats like MP3 and
AAC because the decoder just looks for frames in the file and
doesn’t expect anything else around them. It might not work for
AIFF though. Experiment :)
—Jens
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden