▲

[raina]

Sounds like corrupted samples in both XMPlay (3.4.2.127) and Milky.

[saga]

also sounds and looks corrupted in OpenMPT. i guess the file itself is corrupted.

[Elrinth]

yes you guys are right... how weird... well I redownloaded the xmfile and everything is working fine now.. sorry for worrying ya'll!

thanks for help!

[SmartOne]

Why does a decent number of plugins slow XMPlay's (or Winamp's) startup?  Does it simply take a while to access DLLs in general?

[Ian @ un4seen]

Yep, it takes some time to load each DLL. On top of that, some plugins need to be initialized, and some take longer doing that than others.

[sergeymen]

As has been mentioned before, xmplay ignores the replaygain peak tag, which I hope will change in 3.5 .

An (imperfect) solution has been suggested, which is to set the Auto-amp to "reduction" while enabling replaygain. It's imperfect because the volume reduction could happen in the middle of the track, whereas if xmplay considered the replaygain peak tag, then the adjustment would happen before the track started playing.

The above solution is also non-functional, because of a bug in the auto-amp feature that I would like to report below.

Basically, the auto-amp feature in "reduction" mode (and other modes) doesn't work if replaygain-based volume adjustment is turned on in xmplay. Here are DSP settings that you can use for testing:

And here's a set of files that you can use for testing:

these files have no replaygain information, and they don't clip:
brown noise (mp3)
brown noise (flac)

these are same as above, but with replaygain info added. they clip, regardless of auto-amp settings:
brown noise (mp3)
brown noise (flac)

Replaygain info was added to the files above using foobar2000. Neither set of files clips in foobar2000 because it considers the replaygain peak tag.

I love xmplay and I hope Ian squashes this bug in 3.5 or earlier.

[Ian @ un4seen]

The auto-amp disabling while Replaygain is active (until the amp slider is moved manually) is intentional

In the "stuff" builds, there is a "pre-amp" option that can be used to overcome dodgy Replaygain levels, but I guess it would indeed be a good idea to automatically make use of the peak information when available. Here's an update to try...

   www.un4seen.com/stuff/xmplay.exe

A FLAC plugin update is also required to provide the peak info from FLAC files...

   www.un4seen.com/stuff/xmp-flac.dll

When peak information is detected, it will be shown in the General info window (under "Peak"). If all works well, I'll tidy it up later, but for now a simple "P" checkbox has been added to the "Amplification" options to have the Replaygain level limited by the peak level.

For anyone that is currently using the "pre-amp" option, is that still needed with this new option?

[Brian]

For anyone that is currently using the "pre-amp" option, is that still needed with this new option?

Please help me understand how the two options relate to each other. Many thanks.

[sergeymen]

When peak information is detected, it will be shown in the General info window (under "Peak"). If all works well, I'll tidy it up later, but for now a simple "P" checkbox has been added to the "Amplification" options to have the Replaygain level limited by the peak level.

Thank you for adding this, Ian!

I just tested it out, and I am seeing two issues:

- "P" setting gets reset to unchecked every time I close and re-open xmplay.

- I think the "P" setting gets ignored if "reset on each track" is checked, which is very unhelpful because replaygain doesn't seem to work if "reset on each track" is not checked.

What does work is opening the file that clips with replaygain applied (but peak info ignored), and (with auto-amp and pre-amp disabled) manually checking the "P" option as it is playing. That immediately brings down the volume to a level that doesn't clip.

For anyone that is currently using the "pre-amp" option, is that still needed with this new option?

Please help me understand how the two options relate to each other. Many thanks.

In my understanding, the issue addressed by the "pre-amp" option is separate from the issue addressed by the "P" option. The "P" option is used to make sure that replaygain-adjusted files do not clip (i.e. files that sound "quiet" overall [at least to the replaygain algorithm], but that would clip if they are amplified to a "normal" level)--so with the "P" option checked (and replaygain and peak tag present in the audio file) such tracks would be amplified to the maximum level possible without introducing clipping.

The "pre-amp" option is different in that it addresses the volume differences that result when some files have replaygain information, whereas others do not. Replaygain-adjusted files tend to be quieter than non-replaygain adjusted files, and the pre-amp option can be used to selectively boost the volume of only those files that have replaygain information. I think this option is of some value, but it can also be misused. Replaygain files target a lower perceived volume (someone said 89db) for a reason--because if it targeted a higher volume, more files would clip at the replaygain-recommended levels; so either a lot of files would clip, or instead of clipping their volume would be reduced, which would result in perceived volume differences between tracks that could be replaygain-adjusted, and those that couldn't (fully) be because of clipping. So the point is that I think that the pre-amp feature can be misunderstood and can screw up what replaygain set out to do in the first place  (to equalize perceived loudness of different tracks). If it is to be kept at all, I think it should be targeted at non-replaygained tracks.

[Dotpitch]

- I think the "P" setting gets ignored if "reset on each track" is checked, which is very unhelpful because replaygain doesn't seem to work if "reset on each track" is not checked.

So actually, the peak option doesn't do anything currently when starting a new track? Or does it work when you uncheck 'Reset on each track'?

[Ian @ un4seen]

- "P" setting gets reset to unchecked every time I close and re-open xmplay.

Yep, the setting isn't currently saved. That'll be added once the feature is confirmed as working/useful

- I think the "P" setting gets ignored if "reset on each track" is checked...

Strange, it seems to be working fine in my little tests. Do you have an example file that it isn't working with? Note that the peak level will only limit the Replaygain level, not replace it, ie. if the Replaygain level does not exceed the peak (inverted) then it will be used as is.

[sergeymen]

- I think the "P" setting gets ignored if "reset on each track" is checked...

Strange, it seems to be working fine in my little tests. Do you have an example file that it isn't working with?

I'm testing on the same files I posted originally:

with replaygain (mp3)

without replaygain (mp3)

Something strange is going on here. On my computer, when I open the file that has no replaygain info (confirmed per foobar2k and a separate tagger application), xmplay says that it does have replaygain info (but no peak info). I've tried adding and removing replaygain info to the file, re-downloading it, renaming it, but it's always the same: xmplay says that it has replaygain info when it doesn't! When opening the file WITH replaygain info though, xmplay says that the file has both replaygain and peak info (which is correct).

The other strange thing is that the replaygain info that xmplay shows for the file that doesn't have it--is the correct replaygain value for that file.

The above behavior doesn't happen in the current, normal xmplay version (it correctly says that the file without replaygain info doesn't have it, while the file with replaygain info does).

And when comparing the two files, I am seeing a difference, but then some very strange things sometimes (but not always) happen (amp level jumps to -54db on opening of one of them). Ian, would you take a look and compare the two yourself? I am very confused. 

Note that the peak level will only limit the Replaygain level, not replace it, ie. if the Replaygain level does not exceed the peak (inverted) then it will be used as is.

Yes I know, which is why these files I link to are good examples. If replaygain is applied to them, they exceed the peak (ie clip).

[Ian @ un4seen]

Something strange is going on here. On my computer, when I open the file that has no replaygain info (confirmed per foobar2k and a separate tagger application), xmplay says that it does have replaygain info (but no peak info). I've tried adding and removing replaygain info to the file, re-downloading it, renaming it, but it's always the same: xmplay says that it has replaygain info when it doesn't! When opening the file WITH replaygain info though, xmplay says that the file has both replaygain and peak info (which is correct).

The other strange thing is that the replaygain info that xmplay shows for the file that doesn't have it--is the correct replaygain value for that file.

That'll be XMPlay ("stuff" builds) getting the Replaygain info from the LAME header. There is also a peak level entry in the header, but that seems to be left empty; I guess LAME can't be sure what the peak level is without decoding the file (it could be different from the source file).

And when comparing the two files, I am seeing a difference, but then some very strange things sometimes (but not always) happen (amp level jumps to -54db on opening of one of them). Ian, would you take a look and compare the two yourself? I am very confused. 

I don't seem to be able to reproduce that. What settings do you have in the "Amplification" section? Also, does it matter how you open the file, eg. let it auto-advance, double-click on the playlist entry, or another way?

[sergeymen]

That'll be XMPlay ("stuff" builds) getting the Replaygain info from the LAME header. There is also a peak level entry in the header, but that seems to be left empty; I guess LAME can't be sure what the peak level is without decoding the file (it could be different from the source file).

Yes I see now. I didn't know that Lame stores this information by default! And to make it more complicated, I couldn't find any tool that would remove the lame-generated replaygain header from the mp3 file.

So I had to re-encode this file (from flac) using the --noreplaygain option.

The fact that there's no easy way of removing this header, and that there's typically no peak information--makes me doubt whether it's a good idea to use lame replaygain information (stored in headers) at all. Most other players ignore it also. Better to only rely on tags. It's less confusing.

I don't seem to be able to reproduce that. What settings do you have in the "Amplification" section? Also, does it matter how you open the file, eg. let it auto-advance, double-click on the playlist entry, or another way?

Trying again on a file that doesn't have replaygain stored in lame headers, everything works as it should (I tried both mp3 and flac, both replaygain-tagged and not). Files that would clip if they were fully amplified per replaygain suggestion do not clip if the "P" option is checked and peak tag is present.

[Ian @ un4seen]

The fact that there's no easy way of removing this header, and that there's typically no peak information--makes me doubt whether it's a good idea to use lame replaygain information (stored in headers) at all. Most other players ignore it also. Better to only rely on tags. It's less confusing.

I would guess that most players ignore the LAME Replaygain info simply because they are unaware of it

I don't think the fact that the LAME header can't be removed is a big problem; so long as the file isn't butchered (eg. cropped/concatenated), the info will remain valid. I have now added an XMPLAY.INI option to ignore it though...

   www.un4seen.com/stuff/xmplay.exe

Add a "NoLameRG=1" line (under "[XMPlay]") to activate that.

[sergeymen]

I don't think the fact that the LAME header can't be removed is a big problem; so long as the file isn't butchered (eg. cropped/concatenated), the info will remain valid.

I agree that for most people LAME replaygain headers will remain valid, but I regularly "butcher" mp3 files--especially for electronic music, which can sometimes have long and tedious intros/outros. I use mp3DirectCut to trim down some of these tracks. It's a lossless way of trimming an mp3.

I have now added an XMPLAY.INI option to ignore it though...

   www.un4seen.com/stuff/xmplay.exe

Add a "NoLameRG=1" line (under "[XMPlay]") to activate that.

This is great! I just tested it and it works! Thank you very much, Ian!

[Ian @ un4seen]

I agree that for most people LAME replaygain headers will remain valid, but I regularly "butcher" mp3 files--especially for electronic music, which can sometimes have long and tedious intros/outros. I use mp3DirectCut to trim down some of these tracks. It's a lossless way of trimming an mp3.

I see. In that case, I think it would be a good idea for the software to remove the LAME header when altering the file, or better yet, update the basic "Xing" info and strip-out the extra LAME info.

XMPlay will actually try to detect whether the file has been shortened/extended (by verifying other info in the header), and ignore the header if so. So the LAME Replaygain info would probably be ignored automatically in your scenario.

[amit]

In the new stuff version there is a change with streaming handling. My network files are no longer streaming . They load up  completely to local memory/file and only then start playing.

I went back to v3.4.2.124. No problem with this version.

[Ian @ un4seen]

Strange, I don't recall any recent stream/file handling changes. Did the problem begin with the .133 build, or is that just when you 1st noticed it? Also, what format are the files (does it make a difference?) and how are they sent over the network, eg. is it a HTTP server?

[amit]

My files stream from an http server.

I downloaded a stuff version a couple of days ago after not checking them for a while. Therefor I can't say when exactly this problem started.

I get the same behavior  both with mp3 and wav files though in wavs it is more apparent as the amount of data transfer is larger.

For me it looks as if the connection rate  is restricted. With mp3  the buffer fills up very slowly and with wavs xmplay reconnects every few seconds and restart buffering.

Going back to older version fixes this.