Services & Resources / Wolfram Forums / MathGroup Archive
-----

MathGroup Archive 2011

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: WAV Import[] and Integer16 Issue

  • To: mathgroup at smc.vnet.net
  • Subject: [mg115184] Re: WAV Import[] and Integer16 Issue
  • From: telefunkenvf14 <rgorka at gmail.com>
  • Date: Tue, 4 Jan 2011 04:21:49 -0500 (EST)
  • References: <ifhqe4$km7$1@smc.vnet.net> <ifj6oq$5aj$1@smc.vnet.net>

On Dec 30 2010, 6:05 pm, David Bailey <d... at removedbailey.co.uk>
wrote:
> On 30/12/2010 11:29, telefunkenvf14 wrote:
>
>
>
>
>
>
>
> > Group:
>
> > (Version 8, Windows 7 64-bit)
>
> > Consider the case of importing a 16-bit WAV file, with correctly
> > formed header info.
>
> > If I evaluate: Import["someAudio.wav", "AudioEncoding"], Mathematica
> > tells me, as expected, that I'm dealing with AudioEncoding ->
> > Integer16 data.
>
> > Now, can anyone explain why Import["someAudio.wav", "Data"] would fail
> > to return a list of integers?!? (returns a scaled float)
>
> > Searching MathGroup lead me to ReadSoundFile["someAudio.wav"], a
> > function contained the Audio package. (Note: I'm pretty sure you won't
> > find this function anywhere in the documentation or Audio package
> > tutorial, although Mathematica will spit out a usage message if asked).=
 This
> > function imported the 16-bit file exactly as it should have, as
> > Integer16 data, and I was able to verify the header information by
> > including the option PrintHeader->True.
>
> > BinaryReadList["someAudio.wav, "Integer16"] also works as expected,
> > but then one has to manually chop off the WAV header data. (not an
> > easy task---as an example, different parts of the header use different
> > endian formats.)
>
> > Can anyone confirm the behavior when importing a 16-bit WAV file? Is
> > this a bug or by design?
>
> > -RG
>
> I have always thought that that should document Import and Export
> separately for each data type. As it is, the documentation is incredibly
> vague, considering that this functionality is quite important, and
> clearly has consumed much effort within WRI.
>
> David Baileyhttp://www/dbaileyconsultancy.co.uk

1. This might me a good idea. The way Mathematica currently handles
import/export formats is hard to understand---I say this after having
read the guide on adding import and export formats. (I was reading
with the goal of adding some MP3 capabilities to Mathematica---
currently I'm working on some functions that automate the SoX program)

2. The most frustrating part of my import issue, in addition to the
time wasted, is that there WAS a standard solution that worked
(ReadSoundFile), but it's now abandoned and effectively hidden from
99% of users.

3. Perhaps another route for improvement would be for WRI to provide a
PrintHeader -> True option for any Import[] on a binary format with a
header, along with a HeaderQ function to test whether or not the
header and the info in the binary file are jiving with one another.

-RG


  • Prev by Date: Re: Using Extract where some indices are out of bounds (efficiently)
  • Next by Date: Re: NDSolve, three 2-d order ODE, 6 initial conditions
  • Previous by thread: Re: Using Extract where some indices are out of bounds (efficiently)
  • Next by thread: Re: Combining Slider and SetterBar in Manipulate