Wav with corrupt ID3/LIST placement shoudnt cause complete Read fail

Issue #204 resolved
IJabz repo owner created an issue

Reading a Wav file that doesn't ensure ID3 ends on a even boundary causes the subsequent LIST field to start on an odd numbered byte and not be read correctly, jaudiotagger than fails with

org.jaudiotagger.audio.exceptions.CannotReadException: testdatatmp\test162.wav Failed to move to invalid position to 1267014316 because file length is only 42277701 indicates invalid chunk
    at org.jaudiotagger.audio.wav.WavInfoReader.readChunk(WavInfoReader.java:188)
    at org.jaudiotagger.audio.wav.WavInfoReader.read(WavInfoReader.java:61)
    at org.jaudiotagger.audio.wav.WavFileReader.getEncodingInfo(WavFileReader.java:45)
    at org.jaudiotagger.audio.generic.AudioFileReader2.read(AudioFileReader2.java:55)
    at org.jaudiotagger.audio.AudioFileIO.readFile(AudioFileIO.java:359)
    at org.jaudiotagger.audio.AudioFileIO.read(AudioFileIO.java:196)
    at org.jaudiotagger.tag.wav.WavMetadataTest.testWavRead3(WavMetadataTest.java:1705)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:483)

this metadata error should not cause complete failure of Wav read, it should just ignore the problem metdata.

Comments (4)

  1. IJabz reporter

    Fixed, now recognises IST\u009a rather than LIST field and trys to reread at correct boundary and set flag to indicate not currently at correct boundary

  2. Log in to comment