[FIXED] [BUG] NSF/NSFe playlist incorrect for some files

[nelsonhf]

Hi, i'm using WACUP v1.99.47.23960 with the included NSF/NSFe Player (in_notyansf.dll) v0.9.7 and in some files the playlist gets an incorrect (larger) number of tracks than the actual file has (compared with another player like NSFPlay or plug-in). As an example this is the same file opened with WACUP and NSFPlay:

[dro]

I can reproduce this problem but I don't see why it's happening as it's just using what the nsfplug code is reporting back unless there's something that's changed between the standalone player & what's on github currently (couldn't see any obvious difference). Other nsfe I've thrown at it appear to be reporting the correct number of subsongs compared to what nsfplay is indicating which is odd but then some are also showing more than are expected so I'll have to do some more digging into what's going wrong here.

[edit]
Ok I think I get what's going on here. The files can have a 'playlist size' or a 'total song' which I'm using the later so everything that might be present is going to be extracted. I'm debating what to do & might have to add an option to the preferences to control which value is used when they're different (as your example shows it's a 16 track playlist but is reporting 54 songs though nsfplay doesn't seem to do that so I don't know if that's a quirk of the format or something else). Other ones I've given to it will show a playlist size & the tracks (maybe it's something about the metadata that's provided) so I'll see what I end up doing once I've thrown more files at this.

[nelsonhf]

Thank you, the issue has been fixed in the latest builds. A question: Is it possible to show the track names in the playlist? I tried using the ATF formatting but it only shows the %artist% and %filename% tags (it seams that the plugin doesn't return the tag %title%)

[dro]

I'll have to look into why title is missing as I hadn't noticed it tbh as my playlist items seemed to be showing it whereas it's only via the alt+3 dialog that it's obviously failing to fill the fields when there is the handling to return it like with artist & few other metadata values (which seem to be returned as expected from an initial look).

[dro]

It'll need a new build as the input plug-in is seemingly working fine but with the alt+3 aspect there's a problem with how the core is handling the look-up for filepaths ending like "nsfe::NSF,16,,,0,,0" which is already meant to be dealt with to extract it out as 'nsfe' but something is going awry which I've still to debug further (but have a simple change for that which is better to do anyway). I can't replicate the normal atf handling failing to get the metadata unless you've got those items in the local library & if so then you'll need to try refreshing them as the metadata from that is used instead of always going to the file.

[edit]
I can do it as part of a post-release update patch instead of needing to involve a complete so that'll go up in the next few days.

[nelsonhf]

Hi, thank you for the update. I see you've submitted an update for the plugins and the %title% tag is now being displayed in the Alt+3 window, but maybe some remaping is needed. According to the NSFe specifications I read, track names are stored in a chunk called tlbl (track labels). Perhaps you could remap this as the %title% tag and the game title string from the auth chunk remaped as the %album% tag.

[dro]

Can you provide a copy of that nsfe as I can't seem to find one that matches the one you're showing though I'm in 2 minds about changing the metadata reporting vs what the original plug-in was setup to do which is why it's reporting things in the manner seen.

[nelsonhf]

Sure 

[dro]

It's showing it as it does as the plug-in isn't getting those track specific titles from the nsf library (I don't know why). If that information was there then it would be doing as you're expecting it to do (i.e. the title seen would be used as the album).

Not mentioned, I've already changed the 'year' handling so it'll account for the copyright symbol in that string so it can better extract something that can be used.

I'd also forgotten just how much of a mess all of the vgm related formats are when it comes to the faux metadata they offer & how it can often not map nicely to what the non-vgm formats tend to use.

If I can't find a quick fix for why the nsf library isn't getting it I'll have to come back to this later as I'm time limited this month & need to get the current preview build updated for those ignoring the post-release updates for the playback stuttering problem in 24472.

[nelsonhf]

Thank you very much, with the latest update, all metadata is displayed correctly in the playlist and in the file information dialog box (Alt+3).

[dro]

Thanks for the quick confirmation that it's working ok now. Will move this to the resolved section as hopefully there's nothing else needing to be fixed for it.