I noticed that the lyrics to many of the songs on TMBG's "The Spine" were already in LRCDB, so since I got that album for Xmas I thought I'd tag the files.

On the first song I tried to tag I noticed the bug. This bug happened in 1.2.1, so I downloaded and installed 1.3.0 and started over with a fresh blank file and it still happened.

Here is what I did:

- Removed 1.2.1 from add/remove programs and deleted the leftover files in its folder. This also deleted the INI file so I was sure to be starting over with a fresh installation.

- Installed 1.3.0 and its dependencies file to their default location.

- Opened up the song in Winamp. File name was "Rock - The Spine - They Might Be Giants - 2004 - 01 - Experimental Film.mp3" and it already contains V1 and V2 tags for the song, but no lyrics yet.

- In the plugin options, entered my user name and password for LRCDB. Checked the box that said "auto save if lyrics found"

- Selected "Search on internet".

- It found the lyric at LRCDB just fine, and auto saved the lyric exactly as expected. The lyric looks fine in the window.

- In edit mode the first three lines of the lyric look fine, they look like this:

[00:02.994]The color of infinity
[00:06.157]Inside an empty glass
[00:09.310]I'm squinting my eye

- I close WinAmp.

- I re-open the song.

The second line is now showing as screwed up. The second timestamp is lost, and the third line is concatenated to the second line with the third line's timestamp in its place. Like so:

[00:02.994]The color of infinity
[00:09.310]Inside an empty glassI'm squinting my eye

A binary edit of the file indicates that the timestamp for the truncated line is a byte short of what it should be. In other words, there's usually six bytes between lines, and there's only five bytes for that line.

I believe this has happened to other people. I can even see a place in the LRCDB where the song got re-saved that way. It's another lyric from the same album ("Au Contraire" if I recall correctly) in the database that contains the same error within the first couple lines.

Ok, I won't be near my developpement computer within the next week or so, but as soon as I get back to home from holidays, I'll take a look at this bug. Thanks for the head up

No hurry. Thanks for responding so quickly! Hope you're off somewhere fun.

*bump*

Back from the holidays yet?

Just took a look at it and I think I got it.

It has to do with timestamps that end with &H0D (13) (CR in ASCII) and my filtration of CRLF. The standard is to put only LF in SYLT and to remove CR. I use "replace" and it does remove it correctly the CR for the line, but it also the trailing part of the timestamp if it is 0D like the second line of that particular song as timestamp are followed by the LF.

I'll do the filtration somewhere else, before putting the timestamps in there. Fix will be in 1.3.1.


Thanks for the bug report!

I'm now trying out the fixed executable you sent me, trying to get the tags for "The Spine" off of LRCDB and I'm having trouble distingushing between instances of this bug and instances where the lyrics got saved onto LRCDB pre-bugged.

For instance the song "Memo to Human Resources" is all screwed up now, the song lines following the screw-up-point are all off-by-one-line now. (timestamp is one line early from the actual lyrics for all song lines now)

Can anyone look at this and tell me if the problem is in the source material (the lines at LRCDB) or if the problem is still in the plugin? I'm so confused now.

Interesting. Okay, here's what's happening.

The line where the screw-up existed in the original database? In the case of the song "Memo to human resources", the screw up is on the line "I'm searching for some disbelief that I can still suspend"...

Okay, I fixed that line. Edited that line and put the right timestamp on it.

BUT...

Okay, even though the timestamps look right in the lyric edit window...

When I hit PLAY in winamp, the white cursor point moves forward in correct time with each line...

UNTIL IT HITS THAT LINE

Then it gets desynchronized and it's one line behind.

And it stays that way for the rest of the song.

Yet the timestamps are RIGHT, it's the cursor point that's wrong.


Anyone?

Aha. The problem goes away after I SAVE THE CORRECTION, then the desynchronization gets fixed.

It's only desynchronized while I stay in edit mode immediately after making the correction.

Edit: also works to hit "reformat lyric".

The problem, as it was explained to me, is that changing the number of lines in the song isn't reflected in the time-cursor-position-gird until after the reformat command is done (which happens automatically after a save).

1.3.1b1 seems to be working well without that bug, and, as long as I remember to reformat or save the lyric when I make changes to the edited lyric, doesn't exhibit the desynchronization I reported.

But I have a new one to report:

Sometimes it doesn't put in the opening bracket for the time stamp when I click on the line. I had it happen twice on this song as I was editing it. Attached is a screen shot of what I mean. Note the missing bracket on the last line. I did not accidentally delete the bracket, I am sure that the timestamp appeared exactly as shown as soon as I clicked on the line in edit mode as the song was playing. I was already suspicious about it from an earlier instance, and was watching out for it when it happened.

I wonder if that's related to another thing I've had happen. When editing the lyric, if I try to make an edit to the beginning of a line, such as deleting a line break, or typing a letter at the beginning of a line, I have to repeat the keystroke twice before it will take the edit.

For instance, twice while editing this lyric, I wanted to combine two lines into one. So I moved the cursor to the beginning of the second line and pressed the Backspace key. Nothing happened. So I pressed the Backspace key a second time, and only then did it delete the line break and combine the two lines into one line.

I have found that when using the Ctrl-Up/Down to adjust the timestamp it ignores the next keyboard press. This also affects 'click-as-you-sing' as it will ignore the first character i.e. the opening bracket.

That's a good catch. I'll take a look at it.



Tony, could it be that bug or do I have another separate issue?

Not certain. I do sometimes use control-down-arrow so it's possible that's what the problem was. But until we try a bugfixed version I can't be sure.