next »

[SmartOne]

Why wouldn't he use the Peak value, then...?  (Seems like a good suggestion.)

[Dotpitch]

Why wouldn't he use the Peak value, then...?

The whole point of ReplayGain is to make all tracks have the same percieved loudness. If that were as easy as setting the peak value to the maximum volume, there would be no need for the ReplayGain algorithm. Noone ever suggested the use of the peak value (with a hard limiter or a lower gain) before, so it's not implemented.

I have to lower the Global Volume setting so ONE song doesn't clip?  Lame.  There has to be a better way.

As I suggested before, set the Auto-amp to Reduction (tick 'Reset on new track' to reset to the ReplayGain value on track start). XMPlay's own DSP will avoid clipping by lowering the volume.

[Tsorovan]

Another solution would be to disable ReplayGain altogether.

[saga]

Respecting the peak value would need to check the whole album for the maximum peaks. At least that's how I'd imagine it.

[amit]

As I suggested before, set the Auto-amp to Reduction (tick 'Reset on new track' to reset to the ReplayGain value on track start). XMPlay's own DSP will avoid clipping by lowering the volume.

That's what I do

Respecting the peak value would need to check the whole album for the maximum peaks. At least that's how I'd imagine it.

The standard for replaygain info Analyzers ( I guess flac too) is the scan and insert tags both for peak and for avarage gain .

If the peak value after adding/subtracting gain is still above the defualt 89db then the file/album should be adjusted  according to peak information.

[SmartOne]

As I suggested before, set the Auto-amp to Reduction (tick 'Reset on new track' to reset to the ReplayGain value on track start). XMPlay's own DSP will avoid clipping by lowering the volume.

Then the dynamic range of the file is compromised, and that's no good.

[Dotpitch]

As I suggested before, set the Auto-amp to Reduction (tick 'Reset on new track' to reset to the ReplayGain value on track start). XMPlay's own DSP will avoid clipping by lowering the volume.

Then the dynamic range of the file is compromised, and that's no good.

Fair enough. The alternative is to lower the volume for the whole album (avoids clipping but will mess up the percieved loudness of the complete album) or use an external limiter (for example Tomass Limiter from the Winamp DSP plugin section).

[heftig]

After adding a directory to the playlist, XMPlay seems to think the entire playlist is sorted by filename. So if trying to sort by filename, XMPlay will do nothing.

Only after modifying the playlist order (e.g. by moving an entry) will XMPlay allow sorting by filename.

it's late and i'm tired (-.-)

[Ian @ un4seen]

When more than 1 track is selected, XMPlay will only sort those selected tracks, leaving the rest as they are. So in your example, it sounds like XMPlay is just sorting the new tracks, which are selected as they are added to the list.

[r]

Hi Ian,

I've encountered multiple crashes recently when I hit a certain mp3.
I've uploaded the error log.  Let me know if I should upload the mp3.

Also, I've noticed that the "Change track - Random" shortcut is not really as random as it should.

When I reopen XMPlay and hit the "Change track - Random" shortcut, there seems to be a pattern where it will hit certain tracks.  Not always in the same order, but pretty close... and then hitting the mp3 which crashes.

I'm using XMPlay 3.4.2.72 as I'm typing this.

[EDIT]
I tried the latest "stuff" version and it seems to be fixed!

[saga]

It seems like empty sample slots are treated as 8bit samples in the summery in XMPlay. In the attached example, there are two 16bit samples and an empty sample slot, but xmplay says 1x 8bit, 2x 16bit.

[Ian @ un4seen]

Oops, here's an update to try...

   www.un4seen.com/stuff/xmplay.exe

[SmartOne]

Using vgmstream to play BSTRM files, I noticed that sometimes XMPlay determines a wrong file type for files that are clearly *.BRSTM.  It happens with files with short names.  For example: G10.brstm or E06.brstm result in XMPlay reporting G10 and E06 as filetypes, respectively.  Longer, more "non-numerical" names report the correct filetype (BRSTM.)  All of the files play as they should.  It just seems like a funny glitch.

[Jace]

That sounds like it's a side-effect of supporting Amiga-styled file naming scheme (ext.filename). As file extensions quite often are three letters long (and the file's name longer than the extension), it must think it's named Amiga-style.

[Ian @ un4seen]

Yep, that is exactly what it is

But here's an update that'll be a bit more selective; it'll check that the prefix is actually a known extension and that the suffix isn't...

   www.un4seen.com/stuff/xmplay.exe

[winner]

Two questions/suggestions:

Random Play Order - If "random play order" is enabled, when XMPlay starts to play the list it always plays the first item on the list first. For true randomness, it should start playing with a random item on list. Can this be corrected?

Track Info & Extended Playlist - The text in this window does not wrap. I'd think this could be made as default behavior without much fuss, but perhaps there is a good reason why it does not wrap.

I have searched the forums and unfortunately did not find discussion which would answer my concerns.

Thanks Ian or anyone for your response!
 

[Dotpitch]

Track Info & Extended Playlist - The text in this window does not wrap. I'd think this could be made as default behavior without much fuss, but perhaps there is a good reason why it does not wrap.

Use 'Maximum text width' instead of resizing the Info window to wrap the text. Wrapping in the Extended playlist wouldn't look so nice, as all entries now have the same height

[winner]

My view was the message tab in the information window. I would think that text wrapping would be appropriate. Also, it appears that when viewing the Playlist display, the "maximum text width" paramater really doesn't have an affect.

[Zarggg]

Random Play Order - If "random play order" is enabled, when XMPlay starts to play the list it always plays the first item on the list first. For true randomness, it should start playing with a random item on list. Can this be corrected?

When you press "Play" it always plays the track that is currently selected. If no track is selected, this defaults to the first track in the playlist. If you right-click the play button, it will select a random playlist entry.

[winner]

When you press "Play" it always plays the track that is currently selected. If no track is selected, this defaults to the first track in the playlist. If you right-click the play button, it will select a random playlist entry.

Right; the option "save playback position when closing" has some bearing on this too. I argue though that if someone wants random playback, when starting XMPlay (which plays the last loaded playlist) the application should start with a random item, and not always the first. To me this makes sense for the meaning of "random playback." Probably even when random playback is selected, this behavior should override any status of the "save playback position when closing." To be fair, I don't think that even the folks at Nullsoft have yet achieved this seemingly natural behavior for random playback in Winamp.