3
$\begingroup$

I am learning to develop Music Genre Classification models. I have a dataset in which files are in ".au" format, which I need to convert into ".wav". I used SoX (Sound eXchange) to convert it. With a simple:

sox input.au input.wav

the files are converted smoothly. Which parameters can be lost doing this, which can affect the accuracy of my model?

$\endgroup$
  • 1
    $\begingroup$ What information does SoX show for the .au and the generated .wav files? Try sox --i <filename>. $\endgroup$ – Olli Niemitalo Oct 16 '16 at 11:22
  • $\begingroup$ Input File : 'blues.00000.au' Channels : 1 Sample Rate : 22050 Precision : 16-bit Duration : 00:00:30.01 = 661794 samples ~ 2251 CDDA sectors File Size : 1.32M Bit Rate : 353k Sample Encoding: 16-bit Signed Integer PCM Comment : 'blues.00000.wav' $\endgroup$ – sandepp Oct 16 '16 at 11:27
  • $\begingroup$ And the wav file? $\endgroup$ – Olli Niemitalo Oct 16 '16 at 11:34
  • $\begingroup$ Input File : 'blues.00000.wav' Channels : 1 Sample Rate : 22050 Precision : 16-bit Duration : 00:00:30.01 = 661794 samples ~ 2251 CDDA sectors File Size : 1.32M Bit Rate : 353k Sample Encoding: 16-bit Signed Integer PCM $\endgroup$ – sandepp Oct 16 '16 at 11:36
1
$\begingroup$

From a raw "music" point of view, both .au and .wav file formats may introduce a form of lossy compression, as compared to the basic Pulse Code Modulation (PCM). Partly because some parties to drift away for the standard standard, including mu-law companded versions, there are some inconsistencies in the AU and WAV formats.

As the .au is lossy compressed, what is important is that you do not lose even more information while converting to .wav. From your discussion with @Olli Niemitalo, the information seems preserved. However, I am a little worried that the file sizes are the same (.au file) (I tend to think the .au ought to be smaller, with the basic settings):

The Au file format [...] Originally [it] was headerless, being simply 8-bit µ-law-encoded data at an 8000 Hz sample rate. Hardware from other vendors often used sample rates as high as 8192 Hz, often integer factors of video clock signals. Newer files have a header that consists of six unsigned 32-bit words, an optional information chunk and then the data (in big endian format).

So you can check the header information to be sure of how the .au was compressed, what channels are here, etc. As long as this information remains in the .wav file, the chances of affecting genre classification are very mild.

$\endgroup$
  • $\begingroup$ With python numpy, one could verify if the file is compressed is by reading the raw data and plotting or listening. You can read the .au file as a binary via data = numpy.fromfile('myfile.au',np.int8) and plot the raw data. $\endgroup$ – panthyon Mar 17 '17 at 4:20
1
$\begingroup$

For example µ-law encoding at the same sampling frequency would be indicated by SoX as Precision: 14-bit, Bit Rate: 176k, Sample Encoding: 8-bit u-law. Now both the .au file and the .wav file have identical encoding so assuming SoX does nothing patently stupid, the audio data will be identical. If the .au file has metadata in the annotation field, it will be lost as it is not copied by SoX into the .wav file.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.