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

[Phil Race]

StandardFileFormat as a name doesn't feel quite right but I don't have 
anything
better and its not a big deal.

Did you run any JCK tests that might be affected ?

If yes, then "+1".



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