Debugger stops after 8 calls (VB Net)

[asegal0000]

My test programs stops at the 9th call to the .read statement.
The program freezes, must stop debug.


the calls to this procedure are made in rapid succession
Is there something I am missing here?
I am not getting any fatal or non-fatal msgs.





'these are global declarations
Dim TestUltraID3 As New UltraID3
Dim UltraID3TagExceptions() As ID3MetaDataException

Dim InfoTrack, InfoAlbum, InfoArtist As String


Private Sub getTagDetails(ByVal path As String)
Try
TestUltraID3.Read(path) '<<<<<<<<<<<<<<<< halts here

' ID3v1 tag
If TestUltraID3.ID3v1Tag.ExistsInFile Then
tbTitle.Text = RemoveLeadingNums(TestUltraID3.ID3v1Tag.Title)
tbAlbum.Text = TestUltraID3.ID3v1Tag.Album
tbArtist.Text = TestUltraID3.ID3v1Tag.Artist
End If

'ID3v23 tag
If TestUltraID3.ID3v2Tag.ExistsInFile Then
If TestUltraID3.ID3v2Tag.Version = ID3v2TagVersions.ID3v23 Then
InfoTrack = TestUltraID3.ID3v2Tag.Title
InfoAlbum = TestUltraID3.ID3v2Tag.Album
InfoArtist = TestUltraID3.ID3v2Tag.Artist
End If
End If

'Retrieve any non-fatal exceptions which might have occurred
UltraID3TagExceptions = TestUltraID3.GetExceptions()

If UltraID3TagExceptions.Length > 0 Then
'Dim IndexUltraID3TagException As ID3TagException

For Each UltraID3ContextMetaDataException As ID3MetaDataException In UltraID3TagExceptions
'Display the Message of the non-fatal exception
'MsgBox(UltraID3ContextMetaDataException.Message)
Next
End If

'Catch any fatal exceptions
Catch exc As Exception
MsgBox(exc.Message)
End Try

TestUltraID3.Clear()

End Sub

[MitchHonnert]

Hmmm...I've never had that happen. I use UltraID3Lib in my own audio library app and I scan thousands of files in one session.

Does it always stop at the same file?

If not, you might try this...
When I have a strange problem like this, I'll keep cutting/commenting out lines of the code and try to get the smallest piece of code that will recreate the problem. Sometimes you remove a line of code and it suddenly works and you know you have the offending line. And if you get down to just a few lines of code and the problem still occurs, at least you've narrowed down the scope of the problem.

HTH

- Mitchell S. Honnert

[asegal0000]

I have been doing that --
It appears as if I have a lot of different MP3's that the read fails on....
the .read hangs (does not return) -- anything I can do to change that
(besides making it a thread and canning the thread if it doesn't return within x seconds? [create an asynchronous call]?)

If anyone else wants to try, I have uploaded the file to:
http://www.sendspace.com/file/m42f0m
pw is testmp3

[MitchHonnert]

OK, I downloaded your file -- no password was required -- and found a problem in the ID3v23InvolvedPeopleListFrame class. I'll look at it more tomorrow.

- Mitchell S. Honnert

[MitchHonnert]

I figured out the problem. As happens with these kinds of things, it was a combination of two problems...

1) Your MP3 has a malformed frame.

2) UltraID3Lib didn't properly handle this particular kind of malformed frame.


I try to anticipate certain errors in the structure of the frame, but sometimes it takes an actual example to spotlight a condition that has to be checked for.

The frame in question was the Involved Person List (IPLS) frame. In an IPLS frame, there are two sections: first a description of how the person is involved and second the name of the actual person involved. You can have as many pairs of these data as you wish, but the key is that each of the two sections of the pair has to be terminated. In your MP3, the frame contains the involvement type ("producer"), which is terminated properly and the involved person name, which is not terminated properly. (The frame is encoded using Unicode, so it should be terminated by a double null, but this is missing. If you look at the file using a binary editor, you can see it goes right from the last character of the involved person name to the frame ID of the next frame.)

I've updated the code to check for a missing terminator for the involved person name. UltraID3Lib now will read your MP3 and properly note the exception.

Thank you very much for posting your comments and the example file. I'll include this fix in the next release of UltraID3Lib and make sure to credit you in the release notes.

BTW, do you know what editor was used to add the IPLS frame? I hope it wasn't UltraID3Lib, but if it was, let me know. I'm going to investigate the creation of this frame type in UltraID3Lib, but if it was my lib, I'd like to get independent confirmation. And if it wasn't, I'm curious was did cause it.

- Mitchell S. Honnert

PS: Here's the IPLS standard...

4.4.Involved people list

Since there might be a lot of people contributing to an audio file in various ways, such as musicians and technicians, the 'Text information frames' are often insufficient to list everyone involved in a project. The 'Involved people list' is a frame containing the names of those involved, and how they were involved. The body simply contains a terminated string with the involvement directly followed by a terminated string with the involvee followed by a new involvement and so on. There may only be one "IPLS" frame in each tag.

Text encoding $xx
People list strings

[asegal0000]

No, it wasn't ultra as far as I know.
I'm not sure what was used.

[asegal0000]

Mitch,

do you know when you will do the next release?
I have maby songs that have this problem
(maybe throw an exception to ibdicate error so tags can be rewritten?)