-
Bug
-
Resolution: Fixed
-
P4
-
1.4.1
-
mantis
-
x86
-
windows_2000
Name: jl125535 Date: 07/15/2002
FULL PRODUCT VERSION :
java version "1.4.1-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-beta-b14)
Java HotSpot(TM) Client VM (build 1.4.1-beta-b14, mixed mode)
FULL OPERATING SYSTEM VERSION :
Microsoft Windows 2000 [Version 5.00.2195]
A DESCRIPTION OF THE PROBLEM :
I am converting 16-bit linear audio data into 8-bit mulaw,
and I'm finding that the endian-ness of the mulaw
AudioFormat object affects the output. If I specify little
endian, everything is fine. If I specify big endian, I get
garbage for the samples.
The RIFF headers written are identical (though slightly
wrong, as per my last bug report)
The Tritonus implementation does not have this bug.
EXPECTED VERSUS ACTUAL BEHAVIOR :
Input to my test program: an audio file generated by
JavaSound, with the format:
new AudioFormat( AudioFormat.Encoding.PCM_SIGNED,
8000f, //sample rate
16, // bits per sample
1, // channels
2, // frame rate
8000f, // framesize
true); // isBigEndian
Output from my test program:
Input Format: PCM_SIGNED, 8000.0 Hz, 16 bit, mono, little-
endian, audio data
Output Format 1: ULAW, 8000.0 Hz, 8 bit, mono, audio data [out1.wav]
Output Format 2: ULAW, 8000.0 Hz, 8 bit, mono, audio data [out2.wav]
Expected results:
Play the generated .wav files with Windows Media Player.
out1.wav should sound like "Hello".
out2.wav should sound like "Hello".
Actual results:
out1.wav sounds like "Hello".
out2.wav is garbled.
The two output formats differ only in that one is specified to be big-endian, and the other little-endian. This is superfluous information when the encoding type is ULAW, because ULAW is an 8-bit encoding. The byte-ordering of the AudioFormat object should be ignored. Each sample is only one byte, so does it matter which byte comes first?
At any rate, running test.wav through either filter should not result in a bunch of garbage in place of the original samples. I don't know what javasound thinks it's outputting when I specify "big-endian" ULAW, but it certainly is not a mulaw stream.
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
import javax.sound.sampled.*;
import java.io.*;
public class test {
public static void main(String[] args)
{
try {
AudioInputStream inStream = AudioSystem.getAudioInputStream(
new BufferedInputStream(
new FileInputStream("test.wav")));
inStream.mark((int)inStream.getFrameLength() *
inStream.getFormat().getFrameSize());
System.out.println("Input Format: " + inStream.getFormat());
AudioInputStream stream1 = AudioSystem.getAudioInputStream(
ULAW_FORMAT_1, inStream);
System.out.println("Output Format 1: " + stream1.getFormat());
AudioInputStream stream2 = AudioSystem.getAudioInputStream(
ULAW_FORMAT_2, inStream);
System.out.println("Output Format 2: " + stream2.getFormat());
File outFile1 = new File("out1.wav");
File outFile2 = new File("out2.wav");
AudioSystem.write( stream1, AudioFileFormat.Type.WAVE, outFile1 );
inStream.reset();
AudioSystem.write( stream2, AudioFileFormat.Type.WAVE, outFile2 );
}
catch( Exception ex )
{
ex.printStackTrace();
}
}
public static final AudioFormat ULAW_FORMAT_1 =
new AudioFormat( AudioFormat.Encoding.ULAW,
8000f, //sample rate
8, //bits per sample
1, //channels
1, //frame rate
8000f, // frame size
false); //isBigEndian
public static final AudioFormat ULAW_FORMAT_2 =
new AudioFormat( AudioFormat.Encoding.ULAW,
8000f, //sample rate
8, //bits per sample
1, //channels
1, //frame rate
8000f, // frame size
true); //isBigEndian
}
---------- END SOURCE ----------
CUSTOMER WORKAROUND :
specify little endian for all ULAW 8-bit audio formats you
use
(Review ID: 138505)
======================================================================