Author Topic: 3.8 reports, queries and bugs  (Read 124611 times)

saga

  • Posts: 2179
Re: 3.8 reports, queries and bugs
« Reply #200 on: 26 Aug '14 - 20:54 »
I know this is going to be a really vague bug report, but it seems that XMPlay gets confused when using the "Microsoft Soundmapper" device and changing between several soundcards. In my specific setup, I was using headphones, then unplugged them while XMPlay was paused (which defaults back to laptop speakers), then I plugged in my USB soundcard and continued playing. Now, the sound output was still working, but the playback position was stuck at the end of the song until I seek or advance to another song.

Alt

  • Posts: 69
Re: 3.8 reports, queries and bugs
« Reply #201 on: 30 Aug '14 - 10:32 »
Latest xmplay version (verified 3.8.0.20 & 3.8.0.21, maybe it started earlier) have problems with reading tags of ITunes aac/m4a files. Sometimes message window just doesn't open. If it's already opened and you restart player or load new file, information doesn't show and window itself looks bugged (takes some part of the screen, blurs it etc). Same thing happens when you load m4a file, open 'message' window, than re-open file from Explorer.
Looks like xmplay has problems with reading "iTunMOVI" because after I delete this tag/atom from file (using AtomicParsley) all is fine.
Also I noticed that all versions shows lyrics "in one line" for some files. Problematic file was uploaded to ftp.un4seen.com/incoming
« Last Edit: 30 Aug '14 - 10:43 by Alt »

Ian @ un4seen

  • Administrator
  • Posts: 20389
Re: 3.8 reports, queries and bugs
« Reply #202 on: 1 Sep '14 - 17:15 »
Here's an updated AAC plugin that should fix the problem...

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

Let me know if you still have any trouble with it.

Alt

  • Posts: 69
Re: 3.8 reports, queries and bugs
« Reply #203 on: 1 Sep '14 - 19:18 »
Thank you!
There's also few other atoms that doesn't break anything but shows incorrect data ("artist-track ID" (atID) & "iTunes Catalog ID" (cnID)). Also tags "apple account email address" (apID), "Purchase date" (purd) and "vendor xID" (xid ) shows as "unknown". As all of them contains personal (and not really useful information), I think those atoms could also be removed/hidden.
P.S. If anyone interesing in deleting those "personal" atoms from ITunes files (reduces size by ~0.4 MB) here's batch for AtomicParsley
Code: [Select]
SET -=--manualAtomRemove "moov.udta.meta.ilst.
cd /d %~dp0
atomicparsley "%~1" %-%apID" %-%cnID" %-%atID" %-%plID" %-%geID" %-%sfID" %-%purd" %-%xid " %-%----.name:[iTunMOVI]" -W
or version that also extracts cover/artwork (in the same folder) and deletes it inside file.
Code: [Select]
SET -=--manualAtomRemove "moov.udta.meta.ilst.
cd /d %~dp0
atomicparsley "%~1" %-%apID" %-%cnID" %-%atID" %-%plID" %-%geID" %-%sfID" %-%purd" %-%xid " %-%----.name:[iTunMOVI]" --extractPix --artwork REMOVE_ALL -W
Save it as "del_iTunesID.cmd", place in one folder with AtomicParsley.exe and drag'n'drop file on this batch.
« Last Edit: 1 Sep '14 - 19:43 by Alt »

galleyrod

  • Posts: 10
Re: 3.8 reports, queries and bugs
« Reply #204 on: 2 Sep '14 - 09:54 »
I am currently using version v3.8.0.16, and whenever I try to update to the new build by overwriting exe file I loose all my settings and XMPlay starts as if was launched for the first time. Even if I update the settings to my needs from scratch and save them they are somehow lost when relaunching again.

Attached is my current exe and ini file for analysis.
Thanx,
   

Ian @ un4seen

  • Administrator
  • Posts: 20389
Re: 3.8 reports, queries and bugs
« Reply #205 on: 2 Sep '14 - 17:49 »
There's also few other atoms that doesn't break anything but shows incorrect data ("artist-track ID" (atID) & "iTunes Catalog ID" (cnID)). Also tags "apple account email address" (apID), "Purchase date" (purd) and "vendor xID" (xid ) shows as "unknown". As all of them contains personal (and not really useful information), I think those atoms could also be removed/hidden.

To tidy the tag display up a bit, here's another AAC plugin update, which should exclude non-text "unknown" tags (unknown text tags could still contain useful info)...

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

I am currently using version v3.8.0.16, and whenever I try to update to the new build by overwriting exe file I loose all my settings and XMPlay starts as if was launched for the first time. Even if I update the settings to my needs from scratch and save them they are somehow lost when relaunching again.

That sounds strange. What Windows version are you using and what path do you have XMPlay installed at? Also, is the "Store per-user config/etc" option enabled in the Miscellaneous options page?

galleyrod

  • Posts: 10
Re: 3.8 reports, queries and bugs
« Reply #206 on: 3 Sep '14 - 14:48 »
Ian,

All settings are standard, no per-user-settings, I am running it on two computers:
1. Office - win7 x32
2. Home - win7 x64

Both versions and settings are identical as for plugins, skins. They only differ in music library.
Had no problems before - but after build 16 it is problematic. I will try to set things up again - without the ini file so XMPlay can create it from scratch - will do it at home and post the results.

Elrinth

  • Posts: 130
Re: 3.8 reports, queries and bugs
« Reply #207 on: 9 Sep '14 - 23:57 »
not sure if this is a bug or not.

But previously using XMP-GME to playback SPC (RSN archives) I added the snesamp (in_snes.dll) plugin to the folder, but even tho I type it to be priority for RSN and SPC it still will play those songs in GME.
Somehow xmp-plugins will always prioritize over winamp plugins no matter what you do if the songs are zipped.
« Last Edit: 10 Sep '14 - 00:20 by Elrinth »

Dotpitch

  • Posts: 2871
Re: 3.8 reports, queries and bugs
« Reply #208 on: 10 Sep '14 - 06:26 »
But previously using XMP-GME to playback SPC (RSN archives) I added the snesamp (in_snes.dll) plugin to the folder, but even tho I type it to be priority for RSN and SPC it still will play those songs in GME.
Does the track play properly if you remove xmp-gme?

bradsmithee

  • Posts: 1
Re: 3.8 reports, queries and bugs
« Reply #209 on: 19 Sep '14 - 08:23 »
Loading DSP/amp/etc. presets while a track is playing seems to cause a crash.  Can anyone else confirm this?
« Last Edit: 19 Sep '14 - 08:27 by bradsmithee »

Ian @ un4seen

  • Administrator
  • Posts: 20389
Re: 3.8 reports, queries and bugs
« Reply #210 on: 19 Sep '14 - 16:27 »
I don't seem to be able to reproduce that problem here. Does it only happen when playing a particular file and/or when the saved settings include particular settings, eg. perhaps for DSP plugins? If it does happen with a particular file or settings, please upload the file or settings (XMPLAY.SET) to have a look at here...

   ftp.un4seen.com/incoming/

piovrauz

  • Posts: 967
Re: 3.8 reports, queries and bugs
« Reply #211 on: 30 Sep '14 - 11:05 »
I just switched to logaritmic volume, and noticed that I can't use the mouse wheel to step at 1dB at time.
I'm using VolStep=5, but that is 2dB; VolStep=3 is 1.2dB. How does one obtain 1dB steps?
I tried VolStep=2,5 but it gets treated as VolStep=2.

Ian @ un4seen

  • Administrator
  • Posts: 20389
Re: 3.8 reports, queries and bugs
« Reply #212 on: 30 Sep '14 - 16:45 »
I'm afraid it isn't possible to achieve 1 dB steps in the volume slider. The slider has 101 steps (0-100). In linear mode it translates to a percentage, and in logarithmic mode it translates to -40 to 0 dB (-40 is actually -infinity). That means each step is 0.4 dB (40/100).

piovrauz

  • Posts: 967
Re: 3.8 reports, queries and bugs
« Reply #213 on: 30 Sep '14 - 17:17 »
OK, I understand now, in linear mode 1 step is 1%, and in logaritmic mode it's 0.4dB.
So its bahaviour is different from the amplification slider.
Well, not a big deal if I can't have 1dB steps.

Anyway thanks for the info, and thanks for the logaritmic volume mode too.
I just needed it because of some changes, and it was already there.
« Last Edit: 30 Sep '14 - 18:58 by piovrauz »

saga

  • Posts: 2179
Re: 3.8 reports, queries and bugs
« Reply #214 on: 12 Oct '14 - 15:42 »
I'm pretty sure this has been brought up before, but anyway... ModPlug Tracker and OpenMPT up to and including version 1.19 used wrong filter coefficients. Most notably, the resonance was about half as strong as in Impulse Tracker. This is very noticeable when playing such files in XMPlay, because the filter will sound too strong. Since you already have code in XMPlay/BASS to determine if a file was made with MPT or OpenMPT (including version numbers for the latter), I propose to add a switch that enables MPT's filter coefficients when these versions were used to save an IT file. For reference, here's how the old filter mode in MPT calculates the coefficients:

Code: [Select]
// Cutoff = 0...127, flt_modifier is -256...+256 (modifier from filter envelope)
DWORD CutOffToFrequency(UINT nCutOff, int flt_modifier) const
{
float Fc;
ASSERT(nCutOff < 128);
if(m_SongFlags[SONG_EXFILTERRANGE]) // Extended filter range
Fc = 110.0f * pow(2.0f, 0.25f + ((float)(nCutOff * (flt_modifier + 256))) / (20.0f * 512.0f));
else
Fc = 110.0f * pow(2.0f, 0.25f + ((float)(nCutOff * (flt_modifier + 256))) / (24.0f * 512.0f));
LONG freq = (LONG)Fc;
Limit(freq, 120, 20000);
if (freq * 2 > (LONG)m_MixerSettings.gdwMixingFreq) freq = m_MixerSettings.gdwMixingFreq >> 1;
return (DWORD)freq;
}

float fc = (float)CutOffToFrequency(cutoff, flt_modifier);
const float dmpfac = pow(10.0f, -((24.0f / 128.0f) * (float)resonance) / 20.0f);

fc *= (float)(2.0f * (float)M_PI / (float)m_MixerSettings.gdwMixingFreq);

d = (1.0f - 2.0f * dmpfac) * fc;
if(d > 2.0f) d = 2.0f;
d = (2.0f * dmpfac - d) / fc;
e = pow(1.0f / fc, 2.0f);

// This part is identical to normal IT filters
float fg = 1.0f / (1.0f + d + e);
float fb0 = (d + e + e) / (1 + d + e);
float fb1 = -e / (1.0f + d + e);

Edit: And it seems that offset effects are currently somewhat broken, I've attached a file that should say "I am atomic", instead it restarts the sample from the beginning.
« Last Edit: 12 Oct '14 - 18:00 by saga »

Ian @ un4seen

  • Administrator
  • Posts: 20389
Re: 3.8 reports, queries and bugs
« Reply #215 on: 13 Oct '14 - 15:27 »
I'm pretty sure this has been brought up before, but anyway... ModPlug Tracker and OpenMPT up to and including version 1.19 used wrong filter coefficients. Most notably, the resonance was about half as strong as in Impulse Tracker. This is very noticeable when playing such files in XMPlay, because the filter will sound too strong. Since you already have code in XMPlay/BASS to determine if a file was made with MPT or OpenMPT (including version numbers for the latter), I propose to add a switch that enables MPT's filter coefficients when these versions were used to save an IT file.

XMPlay should already use MPT's filter coefficients when the extended range flag is set. Is the problem you're reporting only with files that don't have that flag set, or is it also happening when the bit is set? Could you upload an affected file to test with?

Edit: And it seems that offset effects are currently somewhat broken, I've attached a file that should say "I am atomic", instead it restarts the sample from the beginning.

Oops. That problem was introduced in the recent IT offset "fix". I'll correct it for the next update.

saga

  • Posts: 2179
Re: 3.8 reports, queries and bugs
« Reply #216 on: 13 Oct '14 - 17:11 »
After some further investigation, the problem in the files (none of them using the extended filter range) I was listening to is not entirely related to the coefficients - they do make a difference (as said, the IT algorithm's resonance is stronger), but the problems lies rather in another bug in those old MPT versions: The filter is not applied at all if the cutoff value is 7F, unless it is entered as a pattern effect (Z7F), and even then it's only applied for the current note.
So basically, in "old MPT mode", the filter should only be applied if cutoff is < 7F, or if a cutoff macro is executed. I think this fix alone would already make those old modules much more pleasant to listen to.
Here's a good example tune, the drum line right at the beginning is heavily filtered in XMPlay, but in MPT it isn't, as the cutoff setting of that instrument is 7F. http://modarchive.org/index.php?request=view_by_moduleid&query=163376

Ian @ un4seen

  • Administrator
  • Posts: 20389
Re: 3.8 reports, queries and bugs
« Reply #217 on: 14 Oct '14 - 16:25 »
So basically, in "old MPT mode", the filter should only be applied if cutoff is < 7F, or if a cutoff macro is executed.

Up to what version of OpenMPT does that apply to? I checked 1.22, and it seems to apply there too, so I guess it didn't stop at 1.19 :)

saga

  • Posts: 2179
Re: 3.8 reports, queries and bugs
« Reply #218 on: 14 Oct '14 - 16:57 »
Well, it's complicated. ;D OpenMPT will use the old behaviour for files that don't have compatible playback mode enabled, e.g. files made with MPT 1.16. So the example I linked will sound the same in all versions. 1.20 was the first version to have the correct filter behaviour, and since it also enables compatible mode by default, it's safe to assume that files saved with 1.20 or newer will use IT's filter behaviour. I can probably also write up some specs for checking if the compatibility play flag is enabled, in case you want to fix it reliably for "new" files made without compatibility playback mode.

Edit: Actually, let me write that up right now. Some of these things may seem horrible, and they are, but luckily I didn't come up with them! ;D
The important data follows after the last sample in IT files, or after all the other ModPlug extensions in XM files (i.e. after the text, MIDI, PNAM, CNAM and plugin settings chunks).

First, the extended instrument settings may follow. This is the case if the four magic bytes "XTPM" can be read. After that an unspecified amount of instrument-related chunks follows, each with 4 magic bytes and an uint16 for the size. There is no indicidation of how many chunks there are, so you know you have read too far as soon as you encounter the "STPM" magic bytes, which indicate the start of the extended song properties.

So, the extended song properties chunk is present if you can read the "STPM" magic bytes. These properties are made up the same way, i.e. after the "STPM" bytes you will find a number of chunks with 4 magic bytes and an uint16 for size. The chunk you should look for has the magic bytes ".FSM" and contains an uint16. If the lowest bit of that uint16 is set, assume compatible playback mode to be enabled. For compatibilty-exported files, which don't have these extra chunks, it's always enabled, and for other files which are not compatibility-exported but have the "STPM" chunk without the ".FSM" subchunk (made with OpenMPT 1.17.02.49 or older, I think), it's assumed to be disabled.
In the same chunk you can also read the precise OpenMPT version that was used to save the file, in the "VWSL" subchunk. It's stored as an uint32, with the highest byte carrying the major major version and the lowest byte carrying the minor minor version (e.g. 0x01170249 would be 1.17.02.49).
« Last Edit: 14 Oct '14 - 17:20 by saga »

Ian @ un4seen

  • Administrator
  • Posts: 20389
Re: 3.8 reports, queries and bugs
« Reply #219 on: 15 Oct '14 - 16:45 »
The chunk you should look for has the magic bytes ".FSM" and contains an uint16. If the lowest bit of that uint16 is set, assume compatible playback mode to be enabled.

OK. Here's an update that should support that...

   www.un4seen.com/stuff/xmplay.exe

saga

  • Posts: 2179
Re: 3.8 reports, queries and bugs
« Reply #220 on: 15 Oct '14 - 19:43 »
Now these old files made with MPT 1.16 sound okay, but I think there's a bug somewhere - in the attached examples, compatible.it has the compatible playback flag set and non-compatible.it hasn't, but in both cases the filter is not applied. In compatible mode, it should be applied just like in Impulse Tracker.

Ian @ un4seen

  • Administrator
  • Posts: 20389
Re: 3.8 reports, queries and bugs
« Reply #221 on: 16 Oct '14 - 15:16 »
I've just realized there's a problem with the ".FSM" support: it's currently assuming that the sample data is plain PCM to calculate the end position, which is of course no good when the sample data is compressed. I don't think there's any way to know where compressed sample data ends without processing it? XMPlay reads all of the headers and pattern data before it loads the samples (they aren't loaded at all when scanning info), so it can't be sure where to look for the ".FSM" header. I noticed in all of the examples I have, the ".FSM" chunk is always the last thing in the file, so is it safe to simply check the last 8 bytes for it?

saga

  • Posts: 2179
Re: 3.8 reports, queries and bugs
« Reply #222 on: 16 Oct '14 - 15:56 »
I wouldn't count on it - New chunks are more likely to be added at the end rather than at the beginning of that chunk in the future. And in fact, if one chooses to embed OpenMPT's MIDI mapping in the file (which is an editing feature, not a playback feature, so it's only stored when it's actually used), these follow after the .FSM chunk. I guess that in the case the last sample is a compressed one, you will probably have to decode it. Since the samples are stored in the same order as their sample headers, calculating the length of the last sample (if it's compressed) is enough.
« Last Edit: 16 Oct '14 - 18:25 by saga »

Ian @ un4seen

  • Administrator
  • Posts: 20389
Re: 3.8 reports, queries and bugs
« Reply #223 on: 16 Oct '14 - 17:55 »
OK. I don't suppose the sample data is likely to contain ".FSM" (followed by 0200h), so here's an update that will simply start looking for the ".FSM" chunk from the start (rather than end) of the last sample...

   www.un4seen.com/stuff/xmplay.exe

saga

  • Posts: 2179
Re: 3.8 reports, queries and bugs
« Reply #224 on: 16 Oct '14 - 18:28 »
Thanks for the fix. I guess this will work well enough for now. I guess to optimize it even further, you could also try reading the first chunk of a compressed sample and skip the amount of bytes that are provided in its header. After all, if there's a non-empty compressed sample, it will have at least that one chunk. It could reduce false positives a bit further. Would decompressing the last sample be that much of an issue while loading, though? :) I suppose in most scenarios people would want to play the file anyway, and it would only affect files that are detected to be made with OpenMPT anyway.