So +1
-phil.
On 5/2/16, 3:01 PM, Sergey Bylokhov wrote:
On 29.04.16 19:06, Phil Race wrote:
Did you run any JCK tests that might be affected ?
If yes, then "+1".
All of them are passed.
The next step will be to update the writers, but I would like to get an
opinions what we should do if the AudioFileStream is longer than the
type support.
- Should our writers report that they support such streams, but save
only the first part of audio data(ex: 0 - unsigned int)?
- Should our writers report that they support such streams, but throw
an IOExceptio during the write?
- Should our writers report that they unsupport such streams? Note that
according to the spec only AU file can support data of any length.
#2 sound worst, #3 sounds best, but compatibility may matter.
-phil.
On 04/07/2016 11:52 AM, Sergey Bylokhov wrote:
Hello,
Please review the fix for jdk9.
Long story short:
I do not know why but we have two similar API to obtain the length of
audio data:
- int precision: AudioFileFormat.getFrameLength()
- long precision: AudioInputStream.getFrameLength()
Problem description:
Usually we create AudioInputStream in two steps:
- Validate incoming data and create the AudioFileFormat.
- Based on AudioFileFormat we create AudioInputStream.
Since the AudioFileFormat stores the data as int, we cannot pass
correct long value to AudioInputStream.
In different places we try to solve this issue differently:
- Sometimes we cast long to int and pass it to AudioFileFormat as is,
and as a result we get the negative number of frames.
- Sometimes we cast to long and reports the negative value as
unsupported, so we cannot handle the data up to the maximum value of
unsigned int(but we should according the specification of some
standards)
In the fix I create the new StandardFileFormat.java which will store
byteLength and frameLength as longs, plus it will make the correct
clipping before passing the value to the super class(AudioFileFormat).
And as a result in all our readers I can read the unsigned data as
long and pass it to the new StandardFileFormat.
Two new tests were added, and the one test now cover all supported by
JavaSound WAV formats.
The next step will be to update the writers, but I would like to get
an opinions what we should do if the AudioFileStream is longer than
the type support.
- Should our writers report that they support such streams, but save
only the first part of audio data(ex: 0 - unsigned int)?
- Should our writers report that they support such streams, but throw
an IOExceptio during the write?
- Should our writers report that they unsupport such streams? Note
that according to the spec only AU file can support data of any length.
Bug: https://bugs.openjdk.java.net/browse/JDK-6729836
Webrev can be found at:
http://cr.openjdk.java.net/~serb/6729836/webrev.01
