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

Torkell

  • Posts: 1169
Re: 3.8 reports, queries and bugs
« Reply #375 on: 19 Dec '15 - 15:15 »
XMPlay seems to be getting confused by extended ASCII characters (such as á): it's saving playlists (including xmplay.pls) using UTF-8, but appears to load them as plain ASCII. This turns, say, "Yongë" (ends in e-diaeresis) into "YongĂ«" (ends in a-tilde followed by double-left-angle-bracket).

3.8.1.12 has this bug, as does the latest stuff version (3.8.1.21). I don't recall seeing this with the 3.7 series.

Ian @ un4seen

  • Administrator
  • Posts: 20437
Re: 3.8 reports, queries and bugs
« Reply #376 on: 21 Dec '15 - 12:09 »
Do you remember when exactly the problem first happened and/or can you reproduce it now? Did you happen to edit the XMPLAY.PLS file outside of XMPlay? Doing that could result in what you describe, if you add any ANSI characters above 0x7F. That's because XMPlay assumes that the entire playlist will use the same character set, so if any part isn't valid UTF-8, then the whole file will be treated as ANSI. That has been the case in all XMPlay releases (since Unicode support was added in 3.1) as far as I recall.

If you haven't edited the XMPLAY.PLS file, then perhaps the problem started after adding a particular file to the list? If so, please see if you can locate which file that was and upload it to have a look at here:

   ftp.un4seen.com/incoming/

Torkell

  • Posts: 1169
Re: 3.8 reports, queries and bugs
« Reply #377 on: 22 Dec '15 - 18:51 »
I think it started happening after I upgraded from 3.7.0.41 to 3.8.1.12. It's happening at the moment - every time I restart XMPlay there's another round of UTF-8 to ANSI mangling. I've not manually edited xmplay.pls.

By binary chopping through a copy of playlist (using Notepad in ANSI mode) I've narrowed it down to "01 Don Quichotte .ogg" (uploaded to /incoming/torkell.zip, along with a test playlist that triggers this bug). If the playlist is truncated before that file then XMPlay loads it without any problems. It's not a new file either - judging by the timestamp I would have added it to my uber-playlist in August 2007!

Ian @ un4seen

  • Administrator
  • Posts: 20437
Re: 3.8 reports, queries and bugs
« Reply #378 on: 23 Dec '15 - 17:38 »
Oh yes, I see the problem now. OGG tags/comments are supposed to be in UTF-8 form, and XMPlay assumes that they will be, but the uploaded file has ANSI characters in its title, which is corrupting the playlist (XMPLAY.PLS) when saved. Here's an update that should detect that and correct it (convert to UTF-8):

   www.un4seen.com/stuff/xmplay.exe

It won't/can't fix the already corrupted playlist entries (you will need to remove those), but it should prevent any more being caused by dodgy OGG tags. Let me know if you do still see the problem happening.

xmp-mod15.dll

  • Guest
Re: 3.8 reports, queries and bugs
« Reply #379 on: 13 Jan '16 - 09:16 »
In my XMPlay plugins folder I have file called xmp-mod15.dll. In Options and stuff > Plugins > Input it shows under name Soundtracker, file type mod. Buttons About and Config are active but don't give any result. That file also don't have any version number.
So my question: what is it? Where I get this file? I don't remember  ::) . I can't find that plugin on the site. Where and when I get em? I don't remember. Do I need em? May be it from earlier versions of XMPlay?

Thanks in advance!  :)

Fraggie

  • Posts: 710
Re: 3.8 reports, queries and bugs
« Reply #380 on: 13 Jan '16 - 11:18 »
In my XMPlay plugins folder I have file called xmp-mod15.dll. In Options and stuff > Plugins > Input it shows under name Soundtracker, file type mod. Buttons About and Config are active but don't give any result. That file also don't have any version number.
So my question: what is it? Where I get this file? I don't remember  ::) . I can't find that plugin on the site. Where and when I get em? I don't remember. Do I need em? May be it from earlier versions of XMPlay?
Remove it. :) XMPlay plays Soundtracker modules on its own now.
« Last Edit: 13 Jan '16 - 11:43 by Fraggie »

saga

  • Posts: 2183
Re: 3.8 reports, queries and bugs
« Reply #381 on: 23 Jan '16 - 23:00 »
Latest stuff seems to be stuck in a loop when trying to play this tune:
ftp://ftp.untergrund.net/users/sagamusix/music/ohc/2016/event_dispatching_thread.it

piovrauz

  • Posts: 967
Re: 3.8 reports, queries and bugs
« Reply #382 on: 24 Jan '16 - 19:03 »
If you open then save that tune with the latest modplug stable (1.25.04.00) and then play it with XMPlay it loads and plays fine.
I also noticed the original file size becames bigger when saved with modplug 1.25, maybe there's something with file compression.

saga

  • Posts: 2183
Re: 3.8 reports, queries and bugs
« Reply #383 on: 24 Jan '16 - 20:56 »
Yes, the file has IT-compressed samples. But it doesn't matter, XMPlay simply should not freeze regardless of file content. ;) It probably freezes when searching for OpenMPT extensions (which are absent as the file was saved in compatible mode), but Ian will surely be able to figure that out without our speculations.

piovrauz

  • Posts: 967
Re: 3.8 reports, queries and bugs
« Reply #384 on: 24 Jan '16 - 21:43 »
Well, I'm sure Ian will find the reason and fix it too.
I just wanted to listen to the module out of curiosity and opened it with modlpug: seeing the popup about the old version I tough of reporting it.

Ian @ un4seen

  • Administrator
  • Posts: 20437
Re: 3.8 reports, queries and bugs
« Reply #385 on: 25 Jan '16 - 13:16 »
The problem is indeed related to searching for OpenMPT extensions (looking for an author tag); it's getting stuck in a loop at the end of this particular file. Here's an update to fix that:

   www.un4seen.com/stuff/xmplay.exe

Let me know if you encounter any more problems.

saga

  • Posts: 2183
Re: 3.8 reports, queries and bugs
« Reply #386 on: 30 Jan '16 - 22:58 »
It seems that XMPlay has gone back to a muddy 20ms ramp-in on IT samples. I've attached an example file that should play a nice crisp bass drum, but it sounds really muddy in XMPlay.

Ian @ un4seen

  • Administrator
  • Posts: 20437
Re: 3.8 reports, queries and bugs
« Reply #387 on: 1 Feb '16 - 14:01 »
That's only when "sensitive" ramping is enabled, isn't it? Sensitive ramping uses the start of the sample data to decide whether it needs to ramp-in (to prevent a "click" sound). In this case, the sample data starts at the maximum level, so ramping-in is applied.

saga

  • Posts: 2183
Re: 3.8 reports, queries and bugs
« Reply #388 on: 1 Feb '16 - 15:07 »
Indeed, that was with sensitive ramping enabled. I considered an approach for OpenMPT like you describe it some years ago, but the rules were too arbitrary for my taste to consider implementing it. However, what I was considering back then was the following: If the DC offset at the start is too high (choose an arbitrarily large value like 50%), assume that it is intentional and do not apply smooth ramping. Indeed it may produce a "click" then, but it would seem that with such a large offset, it must be intentional.
Edit: Or even if ramping is still applied at high DC offsets, it really should not be 20ms long. That's still four times longer than what FT2 did, and FT2 already sounded muddy. I'd argue that even 1ms would still be too long.
« Last Edit: 1 Feb '16 - 17:10 by saga »

Ian @ un4seen

  • Administrator
  • Posts: 20437
Re: 3.8 reports, queries and bugs
« Reply #389 on: 2 Feb '16 - 14:31 »
Indeed, that was with sensitive ramping enabled. I considered an approach for OpenMPT like you describe it some years ago, but the rules were too arbitrary for my taste to consider implementing it. However, what I was considering back then was the following: If the DC offset at the start is too high (choose an arbitrarily large value like 50%), assume that it is intentional and do not apply smooth ramping. Indeed it may produce a "click" then, but it would seem that with such a large offset, it must be intentional.

One possible problem with that is when an offset effect is used. It might not be possible to get an offset at a nice low level, so a high starting level then might be unavoidable rather than intended.

Or even if ramping is still applied at high DC offsets, it really should not be 20ms long. That's still four times longer than what FT2 did, and FT2 already sounded muddy. I'd argue that even 1ms would still be too long.

The length of a "sensitive" ramp-in depends on the level of the sample data, but it shouldn't ever exceed 8ms. Are you sure you're seeing 20ms there? Checking it here in a sample editor, it does appear to be 8ms. The problem is that the sample's "crisp" part is less than 1ms long, so it'll be pretty much lost with any ramp-in.

saga

  • Posts: 2183
Re: 3.8 reports, queries and bugs
« Reply #390 on: 2 Feb '16 - 19:55 »
One possible problem with that is when an offset effect is used. It might not be possible to get an offset at a nice low level, so a high starting level then might be unavoidable rather than intended.
Indeed, offset effects are a problem, but I think in my approach I also excluded those from that particular rule. But for the start of the sample, I think it does definitely make sense to not apply such a long ramping in any case.

The length of a "sensitive" ramp-in depends on the level of the sample data, but it shouldn't ever exceed 8ms. Are you sure you're seeing 20ms there? Checking it here in a sample editor, it does appear to be 8ms. The problem is that the sample's "crisp" part is less than 1ms long, so it'll be pretty much lost with any ramp-in.
Ah, indeed it's not 20ms, I was just confused by the sample's waveform, which stays pretty low for the first 20ms. :)
OpenMPT's default ramp-in is 363µs (16 samples at 44 KHz), so the sample still sounds very crispy there.

Krstfr

  • Posts: 29
Re: 3.8 reports, queries and bugs
« Reply #391 on: 21 Feb '16 - 20:54 »
Tracker and midi files don't crossfade between regular audio files.
Actually it seems to be a bunch of filetypes that don't crossfade.
« Last Edit: 21 Feb '16 - 21:52 by Krstfr »

Dotpitch

  • Posts: 2871
Re: 3.8 reports, queries and bugs
« Reply #392 on: 22 Feb '16 - 06:34 »
Tracker and midi files don't crossfade between regular audio files. Actually it seems to be a bunch of filetypes that don't crossfade.
Do the files have the same sample rate?
Quote from: xmplay.txt
Crossfade: If this is set above 0, track changes will crossfade over the specified duration. Crossfading can only be applied when both tracks have the same sample format. The "Apply sample rate to all file formats" option (see the "Output" section) can be used to ensure that is pretty much always the case.

Krstfr

  • Posts: 29
Re: 3.8 reports, queries and bugs
« Reply #393 on: 23 Feb '16 - 13:07 »
Do the files have the same sample rate?
Quote from: xmplay.txt
Crossfade: If this is set above 0, track changes will crossfade over the specified duration. Crossfading can only be applied when both tracks have the same sample format. The "Apply sample rate to all file formats" option (see the "Output" section) can be used to ensure that is pretty much always the case.
Ooh, thank you. Checking the "Apply sample rate to all file formats" option, fixed it.

Dotpitch

  • Posts: 2871
Re: 3.8 reports, queries and bugs
« Reply #394 on: 23 Feb '16 - 18:44 »
Ooh, thank you. Checking the "Apply sample rate to all file formats" option, fixed it.
You're welcome :).

saga

  • Posts: 2183
Re: 3.8 reports, queries and bugs
« Reply #395 on: 3 May '16 - 22:04 »
Broken module ahead! Sample 6 in shorttune2 has a replen that exceeds the sample's actual length. In this case, ProTracker does not clamp the replen to the sample end, but during playback it will play the data behind the sample end (which might be either the next sample or just some random junk). I propose to fix this by reading as much sample data from the file as the actual length field indicates, but allocate enough sample data for the given replen value and clamp the sample length to the replen length rather than the other way around.

Ian @ un4seen

  • Administrator
  • Posts: 20437
Re: 3.8 reports, queries and bugs
« Reply #396 on: 6 May '16 - 15:55 »
Here's an update that will change the sample's length to the repeat end position in that case, and read the full amount from the file (if available) so that the next sample's data is used (like ProTracker apparently does).

   www.un4seen.com/stuff/xmplay.exe

Let me know if you find it doesn't work well with some MOD files.

saga

  • Posts: 2183
Re: 3.8 reports, queries and bugs
« Reply #397 on: 10 May '16 - 14:03 »
Seems to work fine, thanks :)

Astral Soup Design

  • Posts: 275
Adobe X Un4seen
« Reply #398 on: 26 May '16 - 16:49 »
For weeks, I thought Adobe Fireworks CS6 was having problems with the CopyPaste handler (CTRL-C/V), where the program gets frozen for 5-10 seconds before getting responsive again.

What is the relationship with XMPlay? Well, XMPlay was running at the same time with Fireworks CS6. When I close XMPlay, the CopyPaste routines start working again immediately, without lag.

I don't know how to reproduce this issue or if it is report-able, since that buzztard of Adobe have abandoned the support for Fireworks.
May it be possible to be a problem with an external plugin?

piovrauz

  • Posts: 967
Re: 3.8 reports, queries and bugs
« Reply #399 on: 28 May '16 - 10:02 »
I noticed a small issue.
When a file is tagged with a idv2 tag the first letter of the field label is capitalized, but it isn't if the tag is flac or mp4 type.
For example: in a idv2 tagged file, the info windows would display "Artist: ...., Title;, ....", while a flac file or an mp4 file would end up with  "artist: ...., title, ....".
Is it possible to make the behaviour consistent?