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

[Sergey Bylokhov]

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


-- 
Best regards, Sergey.