I have been doing a lot of lyric tagging with the SYLT plugin lately, and it's working quite well.

However, I've got the following things that I'm having to work around on each and every song. Because I know these things and I'm used to them, I'm able to successfully deal with them. But you might want to have a look at them:

1. The first character of the next input gets eaten if you've just used control-downarrow.

I've now confirmed that this issue, reported by SRhodes in another thread, is definitely the case. After you press control-downarrow, the next thing you type (including the opening bracket of a timestamp if you're in click-as-you-sing mode) will get eaten.

Since it's a known bug, I'm sure you'll find an easy fix for it in the next release.

2. I have to keep hitting "Reformat Lyrics".

If I change the number of lines in a song by adding or removing carriage returns, I have to hit "reformat lyrics". This is known, and you already said you'd consider changing the program behavior.

But I also keep having to hit "Reformat Lyrics" when I add new timestamps. In edit mode, as I'm tagging the song, I often need to scan back a bit and retag a section. I want to use that little white bar on the left edge to find my position in the song. But I can't do that without hitting "Reformat lyrics" because the underlying grid never got updated with the previous timestamp clicks.

Is there any way that the act of clicking to place a timestamp can put the appropriate time index into the underlying grid? Without having to do a full reformat?

3. The time of playback gets gradually desynchronized from the lyric tag.

Earlier I said that this was not a problem when editing the lyric, only when playing it back. I'm now pretty sure that the problem exists in both places. And I think I know why it wasn't a big problem for me:

The act of pausing the song, stopping it, or starting the song in a different place by dragging the playback marker, will temporarily fix the desynchronization and the temporal drift will restart from that moment.

I'm pretty sure we came to the conclusion that this was a WinAmp thing. WinAmp itself has temporal drift if it's dealing with a sound card driver that converts sampling rate between 44.1 and 48 khz. The act of stopping playback resets the "zero point" for the audio driver.

Since I'm always pausing and making little corrections in my tagging passes, then the temporal drift is minimized. So in edit mode I don't tend to notice the problem as much. But in playback mode, you can see it because you're not stopping and starting as much.

I find that the only way I can get around the temporal drift is to pause and restart the song approximately every verse and chorus.

This is a pretty serious issue, because I've downloaded songs from the LRCDB which are badly drifted. When playing back on the empeg (which doesn't have the drift problem like Winamp does), they start off OK and then as the song goes on, the drift gets worse and worse until in the last verse the lyrics are a couple lines off. I have to hand-correct these by retagging them with my pause-each-verse trick.

On those lyrics, it's clear that the guy doing the original tagging never stopped and started. He just went Play, click... click... click... click... submit, and never checked his work with mid-song pauses and such.

There's gotta be something that can be done about this? Some way of knowing when WinAmp is going to exhibit this problem, and correct for it? Or perhaps figure out what the offset is (is it just 44.1 divided by 48?), and just have an optional checkbox in the configuration to automatically compensate for the drift? It could reset the drift compensation to zero each time the song playback is paused/stopped or its time index gets changed manually.

At first I thought I didn't suffer from the lyrics drift issue but further testing has proved that actually, I do. For some reason one album I've done is perfect but the rest exhibit this behaviour.

I tend to go through a track with 'click-as-you-sing' then I'll go back through it 3 or 4 times subtly adjusting it. I'd noticed that pausing or moving the time bar adjusted the timing so after changes I would save, start next track and then go back to the track I was synching. A lot of effort to end up with tracks where lyrics are still out of synch. I've tried different versions of Winamp on 3 different PCs now and hit the same problem each time. That's a good catch so I'll try some where I pause/adjust the track on each verse and see how that goes. My other option was to rebuild an old PC as a linux box and use XMMS.

Quote:
1. The first character of the next input gets eaten if you've just used control-downarrow.

Done!, it's fixed for next release.

Quote:
2. I have to keep hitting "Reformat Lyrics".

I still don't know how to handle the reformat lyrics thing. At first, it was a patch because someone, I think it was TonyC, had a plugin crash each time he re-entered edit mode after saving. Because a lot is being done (Duplication of chorus, Resorting) is done on "reformat" I don't want it to fire everytime. I was thinking of doing a partial reformat, but still thinking of the implications.

Quote:
3. The time of playback gets gradually desynchronized from the lyric tag.

That one puzzles me. I don't observe any time drift at all. BUT, I do all the tagging at once, without stopping the track. I did notice that this kind of unsync was being introduced if I pause/play or seek. As the timing from winamp is the same if we're in Edit or Sing mode, I wouldn't understand that the timestamps would drift in Sing mode if I saved them without Pausing/seeking in Edit. Could you confirm this? According to me, if you pause during edit, you'll have to pause during playback to keep everything in sync. And you can't seek precisly that way. You just can't have both worlds. Or do you observe something else? Also, do the lyrics drift when using emphatic? Using which method? I don't remember having any problem with drifting on emphatic since...since.! Yes, I did notice drifting with VBR and it was because of that that I began to use mlord's mp3tool. And I know what I do here sometimes with VBR: I enter edit mode, save then re-enter edit mode again, stop and then play. That way, the mp3's VBR table is fixed before beginning to timestamp. Maybe you could give it a try.




As you see, the last two are more difficult to fix. Don't expect a result for the next bugfix version (1.3.1).

While I'm thinking of it, does anyone has a suggestion for install. I was thinking of providing a "differential" version, requiring 1.3.0 and simply replacing the exe. I think the whole setup of the plugin is becoming a mess: 2 setup files, the latter being a lot af job to maintain.

I use WInamp 2.74, as I don't like any of the recent ones, and I get the same results under WInamp as on the Empeg. No drift at all, unless I pause or ff/rw while editing. I do need to edit in one run (or multiple runs as long as I start from the beginning each time)

So if you have a different winamp version that may well be it?

Mine is 2.90, but I'm wondering if the type of output plugin has something to do with it?

For example, using wave out versus DirectSound output... Worth an experiment.

The ultimate test would be to create an MP3 file with time-index clicks, sort of like the shortwave Master Clock recording (if you know what I mean), and tag that in various situations. Would be easier to see drift than in a song with lyrics.

Quote:
The ultimate test would be to create an MP3 file with time-index clicks

Here they are:

Constant Bit Rate, ten minutes long


Variable Bit Rate --alt-preset standard, lame 3.96.1

Forgive the lame background song. It's entitled "Public Domain" and it's composed by the crew of a TV show I watch on Z Tele, sort of TechTV in French. They ment to make it that bad to laugh at ADISQ, our local RIAA in Quebec. I had to put a song in there to get enough VBR variance and I thought it would be the "perfect" song :-)



If you need the original wave file is also available for those who want to test further.


Please post your results

Thanks for preparing those files. Very nicely done. I don't know if you got that timing track somewhere or if you made it yourself, but that's very slick.

Since my problem is independent of the bit rate (VBR or CBR doesn't seem to matter), I chose to use the CBR file for these tests:



WINAMP 2.90, load file, press play:

- Watching winamp's clock tick by, it starts out fine and then slowly gets desynchronized from the timing ticks.

- At about the two-minute mark, it's off by half a second.

- At about the four-minute mark, it's off by an entire second, and still getting worse.

- Simply dragging the scroll bar on Winamp to reposition the song index (to anywhere in the file including the middle of the file) will instantly fix the problem. The instant you release the scroll bar, suddenly everything is synched up again and it works perfectly. (Until it starts to slowly drift again.)

- Since the SYLT plugin uses Winamp's clock, of it course follows that behavior exactly.

- I get the exact same behavior whether I'm using WinAmp's "DirectSound Output", or WinAmp's "Wave Out" output.



EMPEG, Play file, observe in INFO:TRACK screen.

- Watching the empeg's clock tick by, it works perfectly and remains exactly synched through the entire duration of the entire file.



So clearly this is Winamp's problem, not yours. But I'd really love to find out what the source of the problem is and how to fix it or work around it. And I'd also like to know if anyone else sees the same behavior in their installation of WinAmp.

You could check out older versions of Winamp.

Good idea, I'll try that.

Another thing. I was chatting with my friend Blake about it, and he says my theory about 44.1k versus 48k soundcard driver sampling rates doesn't seem to fit. If that were the problem, a 3.9khz per second difference should give us a difference of 468,000 samples after two minutes; i.e., 9.5 seconds worth instead of the half-second I observed. So that can't be it.

If WinAmp has this problem on a lot of systems (and I've seen some lyrics submitted to LRCDB which were clearly tagged by someone suffering from this problem, so I can safely assume I'm not the only one), I'm surprised that it's not being reported elsewhere. Google isn't showing anything. In fact, when I google it, the only relevant return is this very thread.

Think it might be some kind of cumulative rounding error?

Also, has anyone had experience with the latest WinAmp version? Should I try that instead of an older version?

Wonderful, wonderful, wonderful. The earliest version of Winamp that I had was 2.81 and that still displays some drift. I didn't know there was a site for older versions. I downloaded 2.74 as mentioned earlier in this thread and it performs perfectly with the 2 sample files. That should make tagging so much easier. Thank you!

I just tried it with 2.74, because that version was reported earlier in the thread by someone who said that they don't have the problem.

I get the exact same drift in 2.74 as in 2.90. And, as was just said, someone else gets the problem in version 5.

So it's beginning to sound like it's not a specific Winamp bug. Or, if it is, at least it's a bug that's been consistent across versions.

Wish I knew what was causing this...

Hmm. Does the audio play too fast or slow or is Winamp's clock inaccurate? Try whipping out a handheld stopwatch and see what happens.

Ooo. Good question. Testing....

Wow.

From the looks of it, the song file plays through the speakers at the exact right speed. It's only Winamp's time-index counter that's wrong.

In fact, if you put up the Windows clock applet (right click on the clock in the task bar and hit properties), you can watch the analog clock's secondhand move exactly in time with the beeps on the audio file no problem, whereas you can see Winamp's clock slowly drifting.

I wonder if Elperepat's plugin could somehow use the system time instead of WinAmp's time? Or perhaps detect a drift difference between the two and somehow compensate for it?

By the way, I just wanted to say that the only reason I'm harping on this is because others have submitted lyrics to LRCDB that are faulty because of this problem, because they didn't know they had the problem. Their submitted lyrics drift up to two seconds by the end of the song.

My goal is merely to prevent bad songs in LRCDB.

Yes, I did it all by myself. I first tried to find a recording of a continuous clock, like CHU here in canada, but after 30 minutes and still no resalt , I decided to do it myself. I used Natural Voices and Audition... pretty easy to do, if you consider I hadn't use it before.


So, I'll try to post to winamp forums regarding this issue. We'll see. I will try with a few other players, just to confirm. Not every one on the winamp forum will have an empeg to compare with :-) They might as well say it's an encoder problem...

And about the latest winamp version. I use the version 5 since 5.01 (now running 5.08d) AND I always get the Lite version (free). When I install, I remove the "Agent", the "video support" and "New skin" or whatever it is called. That way, it's like the 2.x: a simple and efficient mp3 player. In fact, I see no valuable addition, beside support for a few IPC calls they added.

...
...
...
Oh, Oh look here



Back in 2002 they had that bug... interesting :-) Any way to use another decoder than in_mp3.dll??

...
...

Oh, again

So we're there... I'll continue to look around and see if others have found anything better...

Excellent sleuthing.

I'll try that alternative decoder and see if the problem is also solved for me.

If so, I'd recommend offering it for download at the LRCDB site with installation instructions and an explanation of why it's important.

I can't figure out what kind of a file that is. A zip? A GZ? A raw DLL?

7-zip will decompress it.

Sigh. Just what I need, another compression file format.

Winrar opened it for me

in_mpg123.zip.

Thanks, Meatballman. I was able to deal with it simply by upgrading to a more recent release of WinRar, which took care of everything.

Now the question is... there's three DLL's in there: Regular, SSE and SSE2. Not sure which one I should use?

By the way, his installation instructions are:

"Copy in_mpg123.dll to the plugin directory, uncheck Layer III checkbox on the
General tab in in_mp3.dll(the original nitrane decoder) configuration panel.
And, restart winamp."

Yup, this works. Timing is perfect now. I used the one labeled "SSE" because the "SSE2" crashed Winamp. Dunno what the difference is between the three versions.

Someone needs to put this up as a big red blinky thing at the LRCDB site and at the SYLT plugin site. You know, like "BEFORE YOU TAG ANY LYRICS, READ THIS", that sort of thing.

There's a bunch of stuff already in LRCDB that's mis-timed because of this problem... Dunno how to go back and retrofit that stuff without the original authors being responsible for doing it.

THANK YOU FOR THE EXPERT SLEUTHING PATRICK!!!

Streaming SIMD Extensions (SSE) and Streaming SIMD Extensions 2. They are extra processor instructions created originally by Intel that exist in some x86 processors to speed up multimedia processing. If you have a Pentium 4, use SSE2. Athlons and Pentium III's SSE. All else, normal.

Ah cool, thanks for that clarification.

So, to recap, switching to that mpg123 plugin is the solution to the timing problems? If so, any way the plugin could detect which one is selected and complain/warn if it's not the one we want?