<Sound Dev> [9] Review Request: 6729836 JavaSound treats large file sizes as negative and cannot read or skip

[Philip Race]

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
>>>
>>
>
>