Author Topic: 3.4 reports, queries and bugs  (Read 358138 times)

winner

  • Posts: 260
Re: 3.4 reports, queries and bugs
« Reply #775 on: 24 Sep '09 - 01:08 »
Hello ,

I am not sure which of the four to blame : windows(x64), xmplay, photoshop or OnOne photoshop plugin. After photoshop have started  right clicking on the info window button in xmplay shows OnOne menu...
I run Vista 64 but do not have Photoshop installed; no problem here. I'd bet the problem disappears after uninstalling OnOne.

winner

  • Posts: 260
I'm not sure if this is designed behavior, a shortcoming, feature I've missed, or area for improvement in XMPlay. I was not easily able to find a previous discussion on this in the forum:

If I type a stream URL in the Open file(s) dialog, URL box, then click the Open URL button, XMPlay will play the stream and also add it to the list of URL history in the URL dropdown box. If I launch a stream from a Shoutcast link/button (and I believe other online stream links), the stream will play fine but the URL will not appear at a later time in the URL dropdown box.

I'd think that URLs launched from streams such as this should be included in the URL in the dropdown list, as is the behavior of other media players.

Dotpitch

  • Posts: 2871
Re: 3.4 reports, queries and bugs
« Reply #777 on: 29 Sep '09 - 09:13 »
If I type a stream URL in the Open file(s) dialog, URL box, then click the Open URL button, XMPlay will play the stream and also add it to the list of URL history in the URL dropdown box. If I launch a stream from a Shoutcast link/button (and I believe other online stream links), the stream will play fine but the URL will not appear at a later time in the URL dropdown box. I'd think that URLs launched from streams such as this should be included in the URL in the dropdown list, as is the behavior of other media players.
If you start a stream from one of those 'Listen now'-button, your browser downloads the playlist file and has XMPlay open it, so XMPlay does not know what address the file came from. Such a playlist can contain any number of entries, usually mirrors for the same stream, and you probably don't want them all added to the URL history. If you frequently open the same stream playlist, you can use give XMPlay the link to the playlist file in the Open URL box.

Elrinth

  • Posts: 130
Re: 3.4 reports, queries and bugs
« Reply #778 on: 12 Oct '09 - 20:49 »
http://elrinth.mine.nu/archive/J/Joule/caroline%20in%20neon%20(hot%20pants).xm sounds like crap in xmplay. 3.4.2.101
it plays perfectly in milkytracker

winner

  • Posts: 260
Re: 3.4 reports, queries and bugs
« Reply #779 on: 12 Oct '09 - 21:46 »
http://elrinth.mine.nu/archive/J/Joule/caroline%20in%20neon%20(hot%20pants).xm sounds like crap in xmplay. 3.4.2.101
it plays perfectly in milkytracker
Yah, sounds lousy in XMPlay on my machine too.

raina

  • Posts: 1163
Re: 3.4 reports, queries and bugs
« Reply #780 on: 12 Oct '09 - 22:21 »
Sounds like corrupted samples in both XMPlay (3.4.2.127) and Milky.

saga

  • Posts: 2179
Re: 3.4 reports, queries and bugs
« Reply #781 on: 13 Oct '09 - 00:34 »
also sounds and looks corrupted in OpenMPT. i guess the file itself is corrupted.
« Last Edit: 13 Oct '09 - 00:37 by saga »

Elrinth

  • Posts: 130
Re: 3.4 reports, queries and bugs
« Reply #782 on: 15 Oct '09 - 18:11 »
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

  • Posts: 217
Re: 3.4 reports, queries and bugs
« Reply #783 on: 17 Oct '09 - 00:20 »
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?
« Last Edit: 17 Oct '09 - 02:39 by SmartOne »

Ian @ un4seen

  • Administrator
  • Posts: 20400
Re: 3.4 reports, queries and bugs
« Reply #784 on: 19 Oct '09 - 16:39 »
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

  • Posts: 29
Re: 3.4 reports, queries and bugs
« Reply #785 on: 25 Oct '09 - 19:52 »
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.
« Last Edit: 25 Oct '09 - 19:56 by sergeymen »

Ian @ un4seen

  • Administrator
  • Posts: 20400
Re: 3.4 reports, queries and bugs
« Reply #786 on: 26 Oct '09 - 16:50 »
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

  • Posts: 733
Re: 3.4 reports, queries and bugs
« Reply #787 on: 27 Oct '09 - 18:05 »
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

  • Posts: 29
Re: 3.4 reports, queries and bugs
« Reply #788 on: 28 Oct '09 - 05:47 »
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

  • Posts: 2871
Re: 3.4 reports, queries and bugs
« Reply #789 on: 28 Oct '09 - 10:31 »
- 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

  • Administrator
  • Posts: 20400
Re: 3.4 reports, queries and bugs
« Reply #790 on: 28 Oct '09 - 13:06 »
- "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

  • Posts: 29
Re: 3.4 reports, queries and bugs
« Reply #791 on: 28 Oct '09 - 15:24 »
- 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).
« Last Edit: 28 Oct '09 - 15:33 by sergeymen »

Ian @ un4seen

  • Administrator
  • Posts: 20400
Re: 3.4 reports, queries and bugs
« Reply #792 on: 28 Oct '09 - 16:18 »
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

  • Posts: 29
Re: 3.4 reports, queries and bugs
« Reply #793 on: 29 Oct '09 - 04:50 »
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

  • Administrator
  • Posts: 20400
Re: 3.4 reports, queries and bugs
« Reply #794 on: 29 Oct '09 - 16:35 »
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

  • Posts: 29
Re: 3.4 reports, queries and bugs
« Reply #795 on: 29 Oct '09 - 18:01 »
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

  • Administrator
  • Posts: 20400
Re: 3.4 reports, queries and bugs
« Reply #796 on: 30 Oct '09 - 14:05 »
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

  • Posts: 723
Re: 3.4 reports, queries and bugs
« Reply #797 on: 12 Nov '09 - 20:05 »
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

  • Administrator
  • Posts: 20400
Re: 3.4 reports, queries and bugs
« Reply #798 on: 13 Nov '09 - 16:49 »
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

  • Posts: 723
Re: 3.4 reports, queries and bugs
« Reply #799 on: 13 Nov '09 - 20:27 »
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.