# Which parameters should I take care of while converting .au to .wav for Genre Classification

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?

• What information does SoX show for the .au and the generated .wav files? Try sox --i <filename>. – Olli Niemitalo Oct 16 '16 at 11:22
• 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' – sandepp Oct 16 '16 at 11:27
• And the wav file? – Olli Niemitalo Oct 16 '16 at 11:34
• 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 – sandepp Oct 16 '16 at 11:36

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.

• 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. – panthyon Mar 17 '17 at 4:20

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.

The accepted answer is incorrect on one important point. Au may be applied with either lossless (Linear PCM) or lossy compression. Lossless modes only permit LPCM. Lossy modes allow a variety of codecs, including μ-law, A-law, and ADPCM.

Au is an ancient audio container and file format, so I wouldn't recommend using it for 99% of circumstances to begin with, but I wanted to clarify it does have lossless compression capabilities.

Sources cited below.

1. Au file info

"Header file for Audio, .au" (10 November 1992). Sun Microsystems. Retrieved 16 February 2020 from https://pubs.opengroup.org/external/auformat.html

1. "Linear PCM captures and encodes audio without lossy compression."

Linear Pulse Code Modulated Audio (LPCM). (28 February 2017). Library of Congress. Sustainability of Digital Formats: Planning for Library of Congress Collections. Retrieved 16 February 2020 from https://www.loc.gov/preservation/digital/formats/fdd/fdd000011.shtml