Now I am evolving into a project. In this project, we have a 128kbps mp3 library and we need to find which files have the inferior quality, such as noise existed, volume is too small etc.
Sounds like you don't have a reference to the original uncompressed music.If this is true the only thing that can be achieved IMO is looking for issues like temporal smearing with percussion instruments or impulses for electronic music, or other things like unusual tremolo or other effects. But without reference to the original it's often hard to say whether suspected issues are due to mp3 compression or due to an imperfect recording for instance.
Determining which will sound better to a person is a subjective process, and no one that can be readily done by a machine.
Yes?I do think that there is a evaluation rule for the music quality. not only the bitrates can be used to evaluate it(actually bitrates can not be viewed as the accurate quality rule neither:) )
Quote from: saratoga on 16 April, 2012, 09:53:21 PMDetermining which will sound better to a person is a subjective process, and no one that can be readily done by a machine.So what the "quality" setting of every lossy encoder does actually mean?
Quote from: Nessuno on 17 April, 2012, 02:42:42 AMSo what the "quality" setting of every lossy encoder does actually mean?In this case quality has a very specific meaning - how close the audible result is to the original.
So what the "quality" setting of every lossy encoder does actually mean?
And in general, to develop a perceptual model, some assumption on which signal characteristics have more influence on its perceived quality should be made, shouldn't they?
Any advice? It would be better if someone know some open-source project which already has the ability to detect the mp3 files with bad quality.
For the simplicity, for the 1st step, at least I want to detect the noise existed in the music which affect the whole listening experience. Any advices?
You might want to look into SoX audio toolkit. It can be run from the commandline or a batch script, making it possible to deal with a whole bunch of files. It's also open source, like Audacity, which you used to plot that waveform.It has switches to detect silences, which you could modify to make it detect or split that file:http://sox.sourceforge.net/sox.html... scroll down to the silence section.
I have a problem about your advice. As can be seen from the figure, actually, those horizontal wave which I highlighted in the red box is not on the 0 dB line. In other words, the sound track may not be silence in these area, right?
Since you can't hear a DC level, that is still silence.
I'd assumed, perhaps wrongly, that you were displaying Waveform (dB) rather than linear, in which case those were probably only a fraction offset from zero, and setting silence detection to -80 dB might even be OK.The other approach is to plot a spectrogram - which SoX can export as a PNG image. The silences, whether or not they contain a DC offset as shown, would appear as black in all frequencies. That might be easier to interpret or to analyse graphically or numerically, particularly if converted to an ASCII-encoded graphical format like PPM or PGM (part of PNM or Netpbm format family).
 - Yes, I think it's the whole song - It should be black, except perhaps for the very lowest frequencies, but probably for those also. You can show spectrogram view in Audacity - that should be black during the gaps too.