specific tracks getting heavily compressed by musicbee but not other players

[noketa]

it's the track endroll from here: http://bunkai-kei.com/release/bk-k_002/
it appears also with the track quiet (The Day The World Stood Still-mix) from that, but it's less noticeable there because it happens at a specific part of the rhythm.
endroll gets really compressed starting at 0:32, like it sounds extremely heavily sidechained to the kick. it's very noticeable when it transitions to another part like at 1:19. this EP is mixed pretty loudly so I can see how it'd be happening to this but I know it's not supposed to sound like this. the tracks kinda appear to clip when viewed with some programs but it seems intentional since they sound good otherwise.

I tried turning replay gain off but it didn't seem to have an effect. I just noticed that switching output to WASAPI (exclusive) fixes it, but that's less convenient of course. switching to DirectSound doesn't appear to fix it, but using DirectSound on iTunes doesn't produce the same problem. anyone know another fix?

[frankz]

If sending the pure Musicbee signal to your output via WASAPI (Exclusive) fixes it, this means that the path from MB to your ears is clean and is an indication that it is not a MusicBee problem.

[noketa]

If sending the pure Musicbee signal to your output via WASAPI (Exclusive) fixes it, this means that the path from MB to your ears is clean and is an indication that it is not a MusicBee problem.

I wasn't insinuating that it definitely was since this isn't in bug reports, I'm just looking for a different solution. but I'm not necessarily sure it isn't since musicbee could be applying a compensation to prevent clipping when running in shared output.

[frankz]

but I'm not necessarily sure it isn't since musicbee could be applying a compensation to prevent clipping when running in shared output.

I'm pretty sure that's not something MB does.  It will clip if your file clips.

I'd check the file in the tag editor on the settings tab and make sure you haven't inadvertently adjusted the playback volume there, although switching to WASAPI shouldn't negate that.

Maybe do a deep dive on the tags of the file and make sure you didn't do a gain adjustment there (not replaygain tags - MP3Gain style) at some point.  Again, WASAPI exclusive wouldn't fix that, but it's all I can think of.

No other ideas really, and I doubt those ideas have any real hope of being useful.

[noketa]

after looking closer at the files in audacity the files contain like split second values WAY above digital zero. like clipping baked into a track would be trimming the amplitude right at 0, but the clipping ISN'T baked into the track so it just lets the player automatically clip it. so what seems to be happening is it's being compressed in line to bring that peak down to zero instead of what other players do which is just clipping it where it goes above that.

[hiccup]

There must be something going on with either your MusicBee settings or plugins, Windows audio settings, or third party software/drivers that get involved in the audio-path.

[Steven]

if you are playing .m4a files then search the forum for bass_aac.dll

[hiccup]

if you are playing .m4a files then search the forum for bass_aac.dll

Perhaps it would be a good idea for 3.6 to have a warning pop-up the first time that a user is trying to play an Apple file, saying it is strongly suggested to download and use bass_acc.dl.
Maybe even disable playback of such files completely until that has been done.

It would probably save both MusicBee users that are using Apple files and experience issues, and the forum members that are trying to provide support in figuring out what is going on some time.

[alekto]

If using WASAPI (exclusive) resolves the issue but is less convenient, you might want to investigate whether your audio device settings support exclusive mode in a way that doesn't cause the compression issue. Some audio devices offer different modes that affect task manager mc how audio is processed.