View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0021325 | MMW 5 | Playback | public | 2024-11-04 23:06 | 2025-01-20 08:10 |
| Reporter | peke | Assigned To | |||
| Priority | urgent | Severity | minor | Reproducibility | have not tried |
| Status | resolved | Resolution | fixed | ||
| Product Version | 2024.0 | ||||
| Target Version | 2026 | Fixed in Version | 2026 | ||
| Summary | 0021325: Some tracks Play clipped When Re Analyzed | ||||
| Description | Some tracks Play clipped When Re Analyzed Sample track is on FTP have correct Gain Info and clip only after re analyze. | ||||
| Steps To Reproduce | 1. Load track in now playing -> Check Track properties Leveling that should state -1.4xxxxxx 2. Play the track and confirm that it does not play with clipping artifacts 3. Right Click on Track -> Analyze volume 4. Check Track properties Leveling and it is changed to +1.4xxxxxx 5. Play track and track plays with clipping artifacts. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 3402 | ||||
|
|
I do not hear any clipping. Tried also analyze volume in MusicBee and the resulting coefficient was very similar to the one from MM5, I do not see any problem here. Isn't problem elsewhere? Check your "clipping prevention" setting and "Level playback volume" setting. |
|
|
So the problem is, when the user has level playback volume set too high, in this example it is 95dB (standard, used by ReplayGain library, is 89dB). Then even clipping prevention does not help. Tested with MM4 and it is exactly the same, so nothing new, these are limits of used algorithms for leveling. We could try to find some better, but for now, I would leave it as it is, as it is done this way for ages. |
|
|
Postponed to the later release, I will check, whether we could handle this situation better. |
|
|
I revised our very very old code and found bug in clipping prevention implementation, it was not working correctly for target levels different from 89dB. Fixed it and now it seems to be ok. Fixed in build 3072. |
|
|
Verified 3072 |
|
|
Reopening, the fixed caused 0021375. |
|
|
Previous fix reverted, it did not work well and caused regression 0021375. Solution postponed to later versions, as it was such way always, any change will be risky. |
|
|
I analyzed this more and the problem is not in volume analysis (few other SWs give nearly the same value), but in peak analysis. It seems standard ReplayGain algorithm we use does not give good value for this song for some reason. I checked with other SWs and in case they use ReplayGain library they have the same problem and give exactly the same peak "0.977234" like MM. Foobar allows to use "True Peak Scanner", and this gives value "1.036113", with this peak value playback in MM is correct even for target 95dB. |
|
|
Fixed in build 3402. Switched to new library implementing EBU R 128 recommendation and true peak. Current target level is -18 LUFS, recommendation talks about -23 LUFS, but streaming services use from -14 to -18, so I chose compromise which could give good results. We can change, if required. For testing purposes, you can add "UseOldGainLibrary=1" to [Options] section of MediaMonkey.ini, which switches back to original gain library and older algorithms. It is for testing purposes only and probably will be removed later. |
