I did a search and didn't really turn up anything specific. As well I've found a guide on the web that lists some details on how to use encspot to determine the quality of an mp3. Here's what I'm doing, please let me know if there are any more conclusive ways to determine whether an mp3 is screwed up. My questions are in bold face.

What techniques do you use to assess the quality of mp3's without having to listen to them?

Specifically I'd like to know for sure if an mp3 has things like audible skips or blips and what not without having to listen to it. This is especially useful for long mixes that would take a long time to listen to again.

I have the following colums checked in Encspot :

Encoder
Bitrate
Length
Size
Bad Last Frame : This indicates if the mp3 is shorter than it should be, right?
Sync Errors : This would be indicate audible clicks or blips, right?
Quality Index & Lowpass : These two attributes should allow you to guess at what encoder settings were used, right?

I found the following table on another forum that lists the identifiable attributes of different --ap settings. Is it accurate?

:

Thank you to anyone who is kind enough to help.

EncSpot can't do this. Even if the encode was good, there's no guarantee the original WAV didn't have them.

thanks - total duh on my part, overlooked the fact that skips or clicks would most likely be produced during the ripping process and not the encoding process

so there's no way to use encspot information to determine whether there are audible problems with an mp3?

Well, if it indicates yellow or red, there's likely going to be audible MP3 artifacts. But it being green doesn't mean it'll be ok, though.

It may be theoretically possible to detect pops or skips, but EncSpot currently doesn't do it. It'd require some sort of analysis of the actual audio data to look for patterns commonly associated with pops or skips (for example, a skip is typically the complete cessation of music for a split second, with audio immediately on either side of the silence being nearly identical). This might also be rather hard to do when considering that much electronic music has similar patterns on purpose. But at the very least it should be possible to come up with some tool that flags suspicious positions. Not sure if any work has ever been done on this or not.

there ARE of course ways to test your mp3s for missing frames, bad data, etc. I use Encspot's Sync Error column (right click the columns to customize and add it) to test for sync errors in my mp3s after downloading them. You can also use a program called mp3test, which is based off of a commandline tool called mp3check. mp3test will catch all of encspot's errors, but will also catch other "errors" like VBR mp3s, truncated mp3s, etc, errors that do not effect problems with the audio itself. Alas, mp3test isnt configurable to pass over these "errors". If you want to, you can use the commandline mp3check to check your files, it can output lists of problem mp3s depending on the settings you choose. I usually have a commandline set up for each test, as this allows me to find out which problems effect which mp3s. Basically, my process for mp3 cleaning downloaded internet mp3s goes as follows:

1. I use this commandline with mp3check to remove all tag info and cut all bad data from the beginning and end of all the mp3s. I have made sure that my commandline does not "fix" or resample mp3s with missing samples (sync errors).

D:\Utilities\Audio-Video\MP3\mp3check-0.7.3\mp3check --recursive --cut-junk-start --cut-junk-end --ign-resync --ign-bitrate-sw --cut-tag-end D:\Music

ign-resync may not be needed, that may only be needed when using mp3check's testing features. Same with the ign-bitrate-sw. These would be priceless if they worked with the fix-headers option, but i do not think they work with it, but instead only testing, so you would be wise not to use the fix-header option unless you know that your files have no sync errors, and are not VBR.

2. Next I use mp3test or Encspot to find mp3s that are still bad. Those are the ones that I delete, because they are irrecoverable. One note, if you use mp3test in this step, pay attention to bitrate swapping errors, as this usually constitiutes a VBR mp3 that is probably good. You might just use Encspot, as it reccognizes the same sync errors, tho it does not have the file moving options that mp3test has.

3. With what is left, the good mp3s, I run them through mp3trim to remove silence from the beginning and end of the mp3s. Any truncation that occured by removing bad data from the ends of the mp3s with mp3check "disapears" when I do this, because a new clean beginning and end for each mp3 is created.

4. My next to last step is to normalize with mp3gain. After normalizing, I move any files that still clip after radio normalizing to a separate folder to remind me to seach for that mp3 again, hopefully finding a better (more amplified) recording.

5. To fix file namings, I use a program called Mp3Renamer that is no longer supported but is still availiable for download. This program auto capitalizes and fixes common errors. For unique mp3 names, i go in manually, or use a standard mass renamer program (there are many). Next, I use a program called TagScanner to read the filenames and create id3v1 and id3v2 tags. Once this is all done, i use a program called MP3 Rename to create artist directories and to automatically place same artist recordings into these directories.

All of the above is not needed if you use EAC and your own cds, which is what i do for my own albums. I will try to come up with a list of links of the above mentioned programs, i am kind of busy right now tho. I hope with Google you can get yourself started.

In regards to detecting settings used in LAME via Encspot, this works for everything except for the --alt-presets because the LAME tag (which I've stated before as being poorly designed), does not provide for storing information on any of the internal psymodel tweaks that the --alt-presets use beyond standard command line options.

The best you can get is that it's possible that an mp3 was encoded via --aps if it meets certain criteria, but you cannot be positive because it's quite easy to create an mp3 with all of the normal settings of --alt-preset standard, but without any of the code modifications.

For example, try using --alt-preset standard, and then --alt-preset standard --no-preset-tune to create 2 mp3s of the same clip. The first will use all of the internal tweaks the normal --alt-preset standard vbr modes turn on, but the second will only use the normal LAME settings, disabling the extra stuff.

From encspot, these mp3s should look identical in regards to the LAME tag stuff.

Also, the quality index and color coding are useless as a guide to actual measured quality. For example, I believe --r3mix generates a higher quality index than --alt-preset standard.

For the most part, this is really pretty impossible to do in any sort of reasonable fashion.

If you could determine the settings used, that would be one thing, but even then it wouldn't be the ultimate solution. There are still too many samples where mp3 (as a format) fails for a preset alone to be a reliable indication of measured quality..

it would be nice tho. Are new flags possible? Can't programs that transcode (i know this is all up to the author) add a "transcoded" flag along with the "copy" or "copyright" flags? What are the status of these flags anyway? Are they or arent they removeable? I know this would not be directly applicable to WAV downloads because the WAVs would not be flagged, but it would be very nice to read a checked flag that listed that it was transcoded. Since standards are becoming present in LAME settings, why not have a flag for the basic settings built into the coding of the mp3. Encspot tries to use the information that it has in front of it to determine what program encoded it. Why can't we make it easier for Encspot and give it a little more to have in front of it if you catch my drift. As for assessing the quality of the mp3's in respect to pops and clicks introduced during ripping and not in the encoding itself, i guess it is up to the ripper to check his stuff. Any clicks and pops introduced at the ripping stage is the ripper's fault. These cannot be detected easily w/o listening i assume. As for corrupted mp3s, these can be found easily as I explained before.

Adding new flags with the current system isn't very practical. Instead of going in to detail about this again, I'd suggest doing a search on LAME tags.. my comments will probably show up. I've outlined what I think would be a much superior method to what is used now..

It has been a while since this thread, but something made me remember it. I did a fairly exhaustive search and found nothing relevent to the topic. I understand why adding new flags wouldn't be practical. Has anyone come up with a better solution?