FYI: Lowlander moved the bug report to the wishlist because he doesn't see it as a bug.

Seems to be the same as [url=http://www.mediamonkey.com/forum/viewtopic.php?f=1&t=67174]Amazon MP3 download sounds terrible[/url]

Does checking "Clipping prevention" solve the problem? See [url]http://www.mediamonkey.com/forum/viewtopic.php?f=1&t=67174#p345402[/url]

Edit:

Out of curiosity I've tested with "Zigeunerweisen Op. 20 (Gypsy Airs)", Amazon.com Song ID: 202033915 and think I've found the real problem!

[list=1]
[*]The MP3 file from Amazon has no ReplayGain tags at all
[*]When MM analysis the volume, it adds the gain tags:
TXXX="replaygain_album_gain 2.20 dB"
TXXX="replaygain_track_gain 2.20 dB"
[*]In this state, 'Clipping prevention' has no effect! If the user has set a high 'Level Playback Volume To' of more than 89 dB, there is clipping (the louder the more).
[*]When the volume analysis is started manually on that track, MM adds the peak tag:
TXXX="replaygain_track_peak 0.992767"
[*]From now on, "Clipping prevention" works fine and prevents the song from being played too loud, even if the 'Level Playback Volume To' was set higher than 89 dB.[/list]

By the way 'Target Volume for Leveling Tracks' only has an effect on the volume and physical tags when applying 'Level Track Volume'. The volume analysis seems to always use 89 dB for the tag writing.

To sum up for[b] MM users[/b]:
[list=1]
[*]Set both 'Level Playback Volume To' and 'Target Volume for Leveling Tracks' to 89 dB.
[*]Check 'Clipping prevention'
[*]Re-analyse the tracks manually
[*]Never use 'Level Track Volume' on your archive. If you did it with the wrong values and introduced clipping, it is too late and can't be undone[/list]

To sum up for [b]MM bugfixing/development[/b]:
[list=1]
[*]When playing a track with missing replaygain_track_peak value, assume it to be 1 for 'Clipping prevention'!
[*]Set replaygain_track_peak as well when automatically analyzing volumes.
[*]Default should be 'Clipping prevention'=True
[*]User should be warned if he sets values higher than 89 dB (and should be advised to check 'Clipping prevention' ).[/list]

Bug report: [url]http://www.mediamonkey.com/forum/viewtopic.php?f=7&t=67873[/url]

I never had that problem.
Have you checked that the volume rate in tools is 89 db (default rate) ?

I am still experiencing this issue as well (Analyze Volume not fixing it), and have been for some time. I'm about to remove MediaMonkey and find another player.

@nolab, you can always submit a problem track to support if settings don't resolve the issue: http://www.mediamonkey.com/support/index.php?_m=tickets&_a=submit

I've had this problem with both .flac and.mp3 files for at least 6 months now, but "analyze volume" (aka replaygain) is what's CAUSING it. With the option unchecked (i.e., MM ignores the tag it itself wrote), everything is fine. I've tried asking in these forums, but the only advice I got was to lower the rate of gain. I use 92db.

While I appreciate that the poster was trying to help, the fact is that the native gain of many of these tracks is upwards of 100db, and turns to static when I LOWER the output to said 92db. This problem is not replicated in ANY other media player that reads RG tags, but is replicated in separate MM installs on entirely different computers.

As things are, I can't use MM to listen to shuffle, because a songfrom 1989 purrs softly and the next song from 2009 blows me away from the desk (we all know about the "loudness wars"). As such I've been using Winamp for listening, and MM for organizing and tagging.

It sucks, because I paid for a license for a product I really can't use. Again, the files all play normally on every other software, including my Android. All with successful reading of the volume metadata [i]that MM wrote[/i].

Makes no damn sense to me and it's driving me crazy.

[quote="Lowlander"]in most cases is an issue on the users computer resolved with a sound device driver update or an alternative MP3 decoder.[/quote]
Same file plays fine via WMP & even Amazon cloud player from the same computer, so it's not a sound driver nor speaker issue (had tried 3 different sets anyway). And like others here, re-running volume normalization fixed the issue. Likewise, if an alternative MP3 decoder also fixes the issue, then obviously there's an issue with the default decoder.

My point is that MM users should NOT have to troubleshoot the core playback function of a music player.

I had ended up unnecessarily re-ripping huge selections of music because I didn't realize it was a MM bug. I had only realized it's an MM issue after noticing one of the problem "static" songs was purchased directly from Amazon and played fine with the cloud player, then re-tested fine with WMP.

Try telling a typical iTunes/iPod user to install an alternative decoder. "So, you're telling me MediaMonkey's such a great music manager and player? How come it makes these static/pop noises when iTunes plays them fine? Install an alternative what?? No thanks, I'll stick with iTunes..."

FYI, the song in question is "Zigeunerweisen Op. 20 (Gypsy Airs)", Amazon.com Song ID: 202033915.

Did you send in debug logs to support? As this is an issue for very few people it hasn't been reproduced and in most cases is an issue on the users computer resolved with a sound device driver update or an alternative MP3 decoder.

It's been 6 months, and MM 4.0.6 still has this issue. How can MM expect to reach the bigger, layman audience if the core functionality of MP3 playback doesn't work properly without hacks?

Use: http://www.mediamonkey.com/addons/browse/item/mad-input-plugin/

[quote="Lowlander"]If they're MP3 files try the link at the bottom of the linked article: http://www.mediamonkey.com/support/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=101[/quote]
Link to Input Plugins page under "1. in_mad.dll." goes to MM4 Homepage. ?

deleted and installed fresh copy of MAD again and it worked !! Happy days! All the VBR MP3s play without static now.

If they're MP3 files try the link at the bottom of the linked article: http://www.mediamonkey.com/support/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=101

[quote="BlueBull00"]were MP3s with non-standard bit rates (147 bit, 253,bit, etc).[/quote]Those are VBR MP3 files and MediaMonkey should have no issue handling them. You may want to open a support ticket and add a link to one of the files shared on a filesharing like dropbox: http://www.mediamonkey.com/support/index.php?_m=tickets&_a=submit Using the MAD plugin mentioned in the above link still might solve the problem. They could also be MP3Pro files.

Same
Interesting about the non standard bit rates.
It seems even Realplayer is fine with them.

I followed the directions in the link above with no real fix. I actually discovered was unable to correct some of the 1700+ songs I had with static by using analyze volume. I did notice that the songs I could not correct were MP3s with non-standard bit rates (147 bit, 253,bit, etc). They play correctly if I convert them to AAC or use another player(Winamp, WMP, VLC).