4

I had a question previously: Reading wav file in Java

Firstly, I want to read a wav file with Java and get its bytes to process into an array.

Secondly, I will remove the silences of it(this is another question's topic).

After that I will divide that wav file into 1 second pieces(I should handle header problem for that small wav files, this is one of the major problems)

I tried to read wav file with Java with that API, the answer of my previous question. However with that API should I do anything for header or API does it itself and how can I divide that wav file into 1 second pieces with Java. Another API or anything else is OK for me too.

Community
  • 1
  • 1
kamaci
  • 72,915
  • 69
  • 228
  • 366
  • the *.wav* file format is quite simple. I've done FFTs on *.wav* file and wrote the *.wav* reader myself, was quite small code. You first need to figure out the encoding (mono or stereo? 8-bit or 16-bit? the number of samples per second: 44.1 kHz or 22 kHz? etc.) then from that you compute how many samples you need to get one second. – SyntaxT3rr0r May 12 '11 at 13:50
  • @SyntaxT3rr0r: the WAV format is actually only simple if the file is *canonical*, meaning a 44-byte header followed by the samples. A WAV file is actually a RIFF file, and the header information does not have to all be contained in the first 44 bytes (although it *is*, in most WAV files). – MusiGenesis May 12 '11 at 14:05
  • @SyntaxT3rr0r I asked a related question here: http://stackoverflow.com/questions/5983457/problem-with-reading-wav-file-with-java – kamaci May 12 '11 at 19:50

1 Answers1

2

The API you reference will return a double[] array containing the sample data from the original WAV file. All you have to do then is create a bunch of smaller arrays (each one second long) and copy from the appropriate position in the original array into each of the smaller arrays (so that all the original data is copied into the smaller ones). Then just use the writing methods of your API to create actual WAV files from each smaller array.

Using that API means you shouldn't have to worry about the headers yourself (which is a good thing, because they're easy to write but very complicated to read, potentially).

The size of each smaller array is dependent upon the format of the original. If the original WAV file is mono with a 44.1 KHz sample rate, then a 1-second array would contain 44,100 elements.

MusiGenesis
  • 74,184
  • 40
  • 190
  • 334
  • the *.wav* format is using discrete values to store sounds, like, say, 16-bit / 44.1 kHz / stereo. How comes an API transforms these discrete values into a *double[]* array? Methinks something went really badly wrong somewhere :) The OP should be able to do his division doing *"non-destructive editing"* but I somehow doubt an API using *double[]* to store discrete value can be trusted ;) – SyntaxT3rr0r May 12 '11 at 13:47
  • @SyntaxT3rr0r: it's actually pretty normal for an API like this to deal with floating-point and integer (i.e. 32-bit) arrays of samples, as it lets you mix multiple 16-bit sources without worrying about overflow (which would be a huge problem if you were mixing them into a 16-bit buffer). However, using 64-bit types for this (e.g. `double` and `long`) is utterly pointless, and it's also weird that the API doesn't support `short` (16-bit integer) in any way, despite the fact that that's the format of the produced WAV file. – MusiGenesis May 12 '11 at 14:10
  • I asked a related question here: http://stackoverflow.com/questions/5983457/problem-with-reading-wav-file-with-java – kamaci May 12 '11 at 19:50