Incorrectly reading not compressed TENC within ID3v23

Issue #161 closed
IJabz repo owner created an issue

Whatever the problem with the file we should not be throwing IllegalArgumentExceptions

14/08/2016 12.17.46:com.jthink.jaikoz.data.LoadFileWorker:call:SEVERE: Runtime Exception: in record unable to display corrupt file:I:\Music\Ripped Music\Music\Lapdance (Trent Reznor NIN Remix).mp3
java.lang.IllegalArgumentException
    at java.nio.Buffer.position(Unknown Source)
    at org.jaudiotagger.tag.id3.ID3v23Frame.read(ID3v23Frame.java:486)
    at org.jaudiotagger.tag.id3.ID3v23Frame.<init>(ID3v23Frame.java:281)
    at org.jaudiotagger.tag.id3.ID3v23Tag.readFrames(ID3v23Tag.java:579)
    at org.jaudiotagger.tag.id3.ID3v23Tag.read(ID3v23Tag.java:543)
    at org.jaudiotagger.tag.id3.ID3v23Tag.<init>(ID3v23Tag.java:308)
    at org.jaudiotagger.audio.mp3.MP3File.readV2Tag(MP3File.java:232)
    at org.jaudiotagger.audio.mp3.MP3File.<init>(MP3File.java:491)
    at org.jaudiotagger.audio.mp3.MP3FileReader.read(MP3FileReader.java:39)
    at org.jaudiotagger.audio.AudioFileIO.readFile(AudioFileIO.java:354)
    at org.jaudiotagger.audio.AudioFileIO.read(AudioFileIO.java:194)
    at com.jthink.jaikoz.data.mp3.MP3Bridge.loadFromFile(MP3Bridge.java:65)
    at com.jthink.jaikoz.data.FileBridgeFactory.loadFile(FileBridgeFactory.java:120)
    at com.jthink.jaikoz.data.LoadFileWorker.call(LoadFileWorker.java:77)
    at com.jthink.jaikoz.data.LoadFileWorker.call(LoadFileWorker.java:18)
    at java.util.concurrent.FutureTask.run(Unknown Source)
    at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
    at java.util.concurrent.FutureTask.run(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)

Comments (4)

  1. IJabz reporter

    Looking at code there is a definite bug here since this error occurs after it has actually read the frame body okay, the failing call is just to move the pointer to the (supposed) end of frame to read the next frame. I think there must be an error with calculating realframesize when the frame is compressed or encrypted but hoping to get the source data file to determine the error

  2. IJabz reporter

    The problem is actually that if reading an encrypted but not compressed frame we don't slice the buffer so after reading the bytes have already been consumed, the bug only exists in ID3v23

  3. Log in to comment