JDK-4925767 : RFE: Add Properties to AudioFormat
  • Type: Enhancement
  • Component: client-libs
  • Sub-Component: javax.sound
  • Affected Version: 5.0
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2003-09-20
  • Updated: 2017-05-16
  • Resolved: 2003-10-24
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
5.0 b26Fixed
Related Reports
Relates :  
Name: fb126949			Date: 09/20/2003

This RFE is a follow-up to 4666845: Add Properties to AudioFileFormat and MidiFileFormat

The following methods should be added to AudioFormat:

public AudioFormat(Encoding encoding, float sampleRate,
                   int sampleSizeInBits, int channels,
                   int frameSize, float frameRate,
                   boolean bigEndian, Map<String, Object> properties);
Map<String,Object> AudioFormat.properties()
Object AudioFormat.getProperty(String key)

The current AudioFormat class makes it impossible to account for non-trivial formats, like MPEG-I layer 3 (mp3), which has more format qualifiers than the ones provided by AudioFormat. So, as an example, an mp3 file might include these properties:
key="quality", value=Integer(5)
key="bitrate", value=Integer(128)
key="VBR", value=Boolean(false)
It is up to the implementor to properly document the keys and their values.


CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger-beta FIXED IN: tiger-beta INTEGRATED IN: tiger-b26 tiger-beta

EVALUATION ###@###.### 2003-09-20 Important to allow flexible format qualifiers in Audio Format. This will stop the various work-arounds implemented by Tritonus (System Properties, passing of parameters in the URL, and back by ASCII data in the AudioInputStream) and other plug-in publishers. CCC's evaluation: - Properties are not statically typechecked. - Properties are not as flexible as you might think. The set of properties honored by javax.sound must be clearly specified and cannot change between J2SE feature releases. - There is no central specification of the semantics of the properties. Each plugin will define its own set of properties and its own interpretation of those properties. User code that examines or sets AudioFormat properties will thus be no less plugin-specific than user code that manipulates system properties or uses plugin-specific format classes. - Future additions to the AudioFormat class will have to contend with existing interpretations of the properties. If in 1.6, e.g., you add {get,set}BitRate methods to AudioFormat you'll have to figure out how that interacts with an existing "bitrate" property used by (some) plugins. A better way to add format-specific information to AudioFormat would be to either (a) Define format-specific subclasses (MP3AudioFormat?), or (b) Add get/set methods for optional format-specific information. For (b) you could, e.g., define {get,set}BitRate methods which would use the existing constant AudioSystem.NOT_SPECIFIED for formats that don't have a concept of bit rate.

PUBLIC COMMENTS RFE: Add Properties to AudioFormat