Ok, anyone have any idea why some of my MP3's have a strange click sound at the very end of the MP3 (at the very last second of the file). Its not a very loud click, but its audible. It occurs also in PC MP3 players such as Winamp as well as on the Rio Car unit. I'm using Audiograbber 1.81, and using LAME 3.91 as the external encoder in Audiograbber 1.81. I set Audiograbber 1.81 to generate both ID3V1 and ID3V2 tags. Is this ok, or maybe this is the part of the problem?

Thanks for any help.

George

What might be happening (this is just a guess) is that your ripping software is adding text data at the end of the resulting WAV file.

Text data, when pumped into an audio processor, looks like random noise and can produce a burst of static or a click.

Then, your MP3 encoder software isn't taking this extra data into account, and it is assuming that this extra data is audio information, and is encoding it into the file.

That's my guess.

It's interesting you think it may be the text data added to the end of the wav file. As it happens, I did have the option to add Title Info to the Wav files in Audiogragbber selected. I guess that explains the click, and of course the solution is to disable any adding of text info to the end of the WAV files. Thanks.

George

The only reason I knew this was because I've been through it before. But not in relation to MP3s, in relation to creating audio CDs. I had helped a friend make a custom audio CD out of tracks he had supplied, and his software (SoundForge, as it happened) also gave the option to append text to the end of the WAV file, which he blissfully activated without knowing the consequences. We burned the CD (a rather involved process back in those days with an ancient first-generation CD recorder) only to discover the click at the end of each track.

Tony's educated guess is a good one, but should not be the cause behind your problem. I tag all my WAV rips with audiograbber for later encoding. I don't have any pops added to any of my songs.

First, test the ripped WAV to listen for any pop at the end. If there's something there, then it will obviously be present in the encoded file. If it's clean then you can start to look at your encoder settings.

Check these things out and then report back with your Audiograbber settins and how you're using LAME (internal via DLL or external command line). Then we can see if there's anything obvious and make a suggestion for another test you can perform. Good thing you've already ruled out the playback device by testing in Winamp as well.

Bruno

First, test the ripped WAV to listen for any pop at the end. If there's something there, then it will obviously be present in the encoded file. If it's clean then you can start to look at your encoder settings.

Sorry, Bruno, but this might not be correct.

Different pieces of player software might interpret the added data differently. One player might recognize it as a "tag" and skip it, while another might attempt to play every byte up until the end of the file.

The only critical thing is, if there's ASCII text appended to the file, does the MP3 encoder regognize and handle the text, or does it try to encode it? This could be completely different behavior than his WAV-player app.

The reason I say this, is when we were trying to debug the popping problem all those years ago, we kept going back and listening to the original WAV file and it always sounded fine, with no pops. Well, that was because the only app we had which could play WAV files that large was SoundForge, the very program that appended the data in the first place. So of course it skipped the tag on playback. Because of this, it took us longer to find the root of the problem than it should have.

Ok, I just tested a couple of WAV files (with text added to the end) and the MP3s produced from those WAV files. The WAV files have NO clicks at the end, whereas the MP3 files have a click at the very end. Strange but true. So, I disabled the adding of the text to the WAV file in Audiograbber, and ripped a couple more CD's. My settings for the External LAME 3.91 MP3 encoding process is "--r3mix -q0". WAV files are set to be deleted, and all WAV files are ripped first, then encoded after all WAV ripping is finished.

One thing I've noticed is that Audiograbber seems to be having problems writing correct VBR header info, since almost all of my MP3's encoded through it have times at least double what they should be. Easily fixed using a number of MP3 progs, but strange nevertheless. Also, the V1 and V2 ID3 tags are slightly different. I set up Exact Audio Copy with the same Lame external encoding settings, and I've found that the VBR headers are exactly correct and no fixes have to be made as well as the ID3 V1 and V2 tags are identical as well. I only wish EAC would automatically create the Artist and Album directory automatically. That's about the only thing Audiograbber does better. But it's probably less hassle to create the dir's manually than to have fix (if automatically) all the MP3 VBR headers.

George

"I only wish EAC would automatically create the Artist and Album directory automatically."

EAC will create the directories for you - you can specify the way you wan the names to look in the EAC options.

Ok, I just tested a couple of WAV files (with text added to the end) and the MP3s produced from those WAV files. The WAV files have NO clicks at the end, whereas the MP3 files have a click at the very end.

What did you test the WAV files in? I bet they'd click if you played them on the car player, which doesn't grok tags on WAV files. As Tony said, your WAV player application may be deceiving you...

Peter

Actually Tony, I'm not wrong. Every single of my MP3s would have this problem if it were inherent to AG and/or LAME. AG uses the tags and as far as I know doesn't pass the raw file to LAME.

Bruno

You have something set incorrectly in AG. Do you have the STD I/O option selected on the MP3 tab? If so disable it.

I do all my ripping without any encoding and then do batch encoding.

I'll get back to this thread with my settings.. No time right now.

Bruno

I'm running same software set up and not getting any clicks....What bit rate? I am using VBR4.

Well, to answer some questions in previous replies...... I tested the WAV's in winamp, as well as the MP3's. Of course, the MP3's were also tested on the player, since that's where I first noticed the problem.:) I may try playing one of the 'suspect' waves on the Rio. I suspect I won't hear anything, since Winamp didn't either, and its been consistent with the MP3's as well, but you never know.

Yes, I do have the "STD IN/STD OUT as Data Stream" selected in Audiograbber, as well as the "Use Encoder as internal decoder". Do you think its possible those are the problem. One thing I know for sure, if I disable the "Append ID3 info to WAV file" option, the click at the end of the MP3 files is gone.

I prefer to do all the ripping and encoding together, since its less work that I have to do.

My encoding settings are "--r3mix -q0" using LAME 3.91

Thanks for all the helpful suggestions.

George

I know for a fact that if you disable the STDi/o as well as "use as internal encoder" options your problems with odd-lengths will be gone. I'd also be willing to bet that you'll lose the problem with the popping at the end.

Now is where Tony's theory comes into play. It may be streaming the full contents of the WAV to the encoder. And the non-music data is causing the pop. If you disable the options mentioned, it doesn't do this.

To use LAME externally, you should not select any special options on the MP3 dialog inside the External Encoder tab. You should only delect the path to your encoder and "User Defined" for argument type. Then specify your command line arguments. I identified these (with the exception of the popping) and a few other problems when changing those settings and reported them to Jackie during the beta of 1.81.

Bruno

By the way, ripping and encoding together is a lot more work, not less. If you do ripping wihout encoding, you can get through a lot more music. Or the same amount of music in much less time. Then just wait for when you have a large amount of data to be encoded and drag and drop the WAV files onto AG while you won't be using your computer (or while you're using it, if you don't mind the slowdown). I normally queue up about 30GB of WAV files and then do a batch encode when I leave for work in the morning. This is the "power user" way to use AG. I'm sure someone on the AG forum has made a FAQ on setup/usage.

Bruno