APE, TTA and WV files with Æ sign play only from drive C on Windows 10

[Wineroz]

A peculiar bug I have stumbled upon



If a file is either in the Monkey's Audio APE], True Audio [TTA] and WavPack [WV] audio format and its filename has in it the

code:
Æ

sign somewhere, then it can only be played in Winamp when that file is located on drive C. Clicking on that file when it is located on a drive that has any other letter [D, M, T etc.] only loads it to the Winamp but does not play it in case of APE and WV, while in case of TTA results with a pop up box containing an error message saying

Can't open file:
A

[where that >>A<< stands always where >>Æ<< should be; so for example the message displays "Lux Aterna" instead of the clicked "Lux Æterna"]



And what is interesting / what I have noticed so far:

1] If that very same file is located on drive C and the shortcut to it is created and then that shortcut is moved and placed on other drive- then it can be played. In other words: LNK shortcut file residing on e.g. drive D when clicked on that drive, suddenly is able to successfully execute playback of the audio file in Winamp which is located on drive C. But it does not work the other way around: a LNK on drive C will not play an APE / TTA / WV file with >>Æ<< that is located on some other drive

2] It does not matter if a file is clicked [thus sent to Winamp from] Windows Explorer, FreeCommander [Build 770 32-bit public] or Mp3tag [3.00c]. The result is always the same: negative

3] Other players do not seem to have such problem. I tested VLC Media Player 3.0.7.1 Vetinari and Media Player Classic 1.9.1. I can drag and drop files to them from the three aforementioned pieces of software in apparently any audio format

4] All audio formats on my operating system are associated with Winamp. But I tested associating APE with the two aforementioned other players and then they had no problem with playback of file containing >>Æ<< sign

5] Formats FLAC, MP3, M4A WAV, WMA can have Æ sign it their filenames and be played form drives other than C. They behave normal, i.e. like all of the other of my audio files

6] I did not had that problem a year ago when I ws still using Windows 7 x64




So at first it seems that it is a problem of plugins that I am using. But that [unpractical] workaround with LNKs in overall and TTA's error message in particular prove that it is the fault of the operating system - because Winamp in theory cannot process the >>Æ< sign but the LNK shortcuts somehow make them digestible for Winamp [most likely by turining >>Æ< into >>A<<]





I am using

Winamp 5.8 Build 3666 Beta

with

WavPack Decoder v2.8.1
Conifer Software
build date Nov 9 2010

TTA Audio Decoder v3.5 (x86)

Monkey's Audio Player v4.18
Matthew T. Ashland

on

Windows 10 Enterprise x64 18362.535

[MrSinatra]

truly bizarre. i would transcode any lossless to ALAC.

[Wineroz]

truly bizarre. i would transcode any lossless to ALAC.

If I would re-covert some files in some audio format every time I run into an issue with them, I would have run out of audio formats a long time ago; or would be gong in circles through them

And there is a reason why I use 3 different lossless audio formats- because that way I can tell part 3 sorts of files right away [and apart from that one lossy one]



I just cannot use switch-to-ALACs workaround

[MrSinatra]

I have no idea what u mean?

However, u picked 3 obscure lossless formats to use.

Flac and ALAC (as m4a) are extremely popular and standard.

I had some lossless in ur formats and others, like shorten, years ago; long since transcoded first fo flac, later to alac, and nary a problem since.

[Wineroz]

What I meant was this: I need to use audio formats that do not create additional problems; and I need to use more than one audio format for convenience of the workflow and to prevent mistakes. [Some file formats do not allow to use certain special characters or allow but treat them as various indicators / markers. And I use one and the same icon for every audio format but in different color in order to differentiate between them because every format means something different in my system of audio files]


I already use FLAC and M4A: FLAC as a go-to-format with the M4A for very special purpose. [But it seems now that main issues with M4A that I had in regards to Mp3tag are now gone- so I think I can start using M4A instead of TTA or examle, while using TTA forthe purpose for which M4A I utilize now]




As for the Æ issue- do you confirm existence of such bug?

[MrSinatra]

I try to eliminate odd characters and diacritics. I do have some, but not many. Idk about that one... did bush or a perfect circle or someone like that use that symbol?

I think ALAC in a m4a will probably do everything u want.

[Wineroz]

I try to eliminate odd characters and diacritics.
[...]

And I do not

I cry hard every time I have to replace some unusual sign with an ordinary one

I think ALAC in a m4a will probably do everything u want.

Except allowing me to efficiently write tags in them? [http://forums.winamp.com/showthread.php?p=3196341]



Going back to the issue itself



Can anyone confirm this bug?

[MrSinatra]

Generally speaking its a very bad idea to write to a file with one app, while another app is currently using that same file. I am surprised u can do this at all with any format actually, but I would advise against it.

If however u insist, and things work the way u say, then why not transcode everything to FLAC and just use that?

[Wineroz]

[...]
why not transcode everything to FLAC and just use that?

Because every audio format that I use carries as such an info about what kind of file it is. My FLACs are fully edited top-notch files, while e.g. TTAs are merely "pre-FLACs", that can either be deleted without a sweat or be with time left alone or edited further into fully "legit" audio

And on top of that creation dates of file are also important. And there is also some other my internal markings visible in a made-up-by-me tag field



All in all I wish I had only FLACs and with one kind of marking in that fields. [But it will newer happen]

[Wineroz]

[...]
then why not transcode everything to FLAC and just use that?

Because
[...]

More thoroughly about that:

http://forums.winamp.com/showpost.php?p=3072712&postcount=10

[Worez was my previous account]

[Wineroz]

I have now a new machine with an up-to-date Windows 10 installed from scratch - and that bug is still there. And I have also checked now the very same files again in other up-to-date players. Conclusion:

Winamp is unable to play APE / TTA / WV files if they have the >>Æ<< sign in them and the files are not located on drive C



This is truly some kind of a MÆtrix level stuff

[ariszlo]

My guess is that it might be related to what filesystem you have on which drive.

Windows uses UTF-16 encoding on NTFS volumes and legacy codepage encoding on FAT32 volumes. Chances are that your C drive is formatted for NTFS (the filesystem preferred by Windows 10) and your other drives are formatted for FAT32.

What happens if you format a usb stick for NTFS, copy the file with the Æ in its filename on it and then try to play the file with Winamp?

[Wineroz]

My guess is that it might be related to what filesystem you have on which drive.
[...]
What happens if you format a usb stick for NTFS, copy the file with the Æ in its filename on it and then try to play the file with Winamp?

All of my drives are set to: GPT, Simple, NTFS, allocation unit size 64 KB. [The drive with the system of course choose 4 KB for itself an also created an EFI volume on it]

The same files on such formatted pendrive behave in the same way: Winamp cannot play them while other players can

[Wineroz]

I see that this will not be resolved. Hopefully Windows 11 will make this go away


So for now I am using a workaround: I have copies of those "faulty" files on drive C - and to those copies I created LNK shortcuts and placed them in the folder where the original "faulty" files are stored. This way the LNK are loaded to Winamp - thus copies are being played