Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Is it true that v1.4 can't even handle .ape? (Read 2078 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Is it true that v1.4 can't even handle .ape?

I can understand probably why .tak can't be supported, but I didn't expect .ape to be ineligible. Many existing windows components simply don't work? Thanks.

Re: Is it true that v1.4 can't even handle .ape?

Reply #1 –
Not sure, what you're talking about.
This APE file sample plays fine for me in 1.4.
TAK should also work, at least it did back in 2017 (provided via ffmpeg) according to the Android changelog.
Would have tested it as well but there don't seem to be any sample files on the net and I'm too tired to convert some on my own.

Re: Is it true that v1.4 can't even handle .ape?

Reply #2 –
Both my Monkey's Audio and TAK files play perfectly perfect on my iPhone.

Re: Is it true that v1.4 can't even handle .ape?

Reply #3 –
Quote from: pyr452 on
Not sure, what you're talking about.
This APE file sample plays fine for me in 1.4.
TAK should also work, at least it did back in 2017 (provided via ffmpeg) according to the Android changelog.
Would have tested it as well but there don't seem to be any sample files on the net and I'm too tired to convert some on my own.

Sorry for not being clear. I was referring to the Android v1.4 version on my Pixel 7 Pro. No issue with iOS v1.4 on my iPhone 13 pro max. The problem occurred whenever i use ftp software to transfer the .ape and .tak files over from my windows 11. And they are 100% failure during transfer. So I thought to myself this must be due to the program not supporting these file formats to begin with. I guess I was mistaken in one way or another if now there are two people describing they can. But even though I have used another method of transfer called "nearby share" and the file lands in the path called "Internal Storage>Music>, it's still not visible on v1.4. So I must say something is still off here. 

Regarding .Tak, how do we add  ffmpeg to Android/iOS? Thx

Re: Is it true that v1.4 can't even handle .ape?

Reply #4 –
There seems to be a problem with FTP transfers occurring for some users - see also: https://hydrogenaud.io/index.php/topic,124830.0.html

However I can't reproduce any of this. What FTP client do you use to send files?

Both TAK and APE are properly supported, including latest APE format revision (10.x). The problem you're seeing must be bad file transfers.
Microsoft Windows: We can't script here, this is bat country.

Re: Is it true that v1.4 can't even handle .ape?

Reply #5 –
Quote from: Peter on
There seems to be a problem with FTP transfers occurring for some users - see also: https://hydrogenaud.io/index.php/topic,124830.0.html

However I can't reproduce any of this. What FTP client do you use to send files?

Both TAK and APE are properly supported, including latest APE format revision (10.x). The problem you're seeing must be bad file transfers.

Thanks, Peter. I have been using FlashFXP client 5.4.0 build 3970 at https://www.flashfxp.com/download to transfer. Only .jpeg, .png, .ape, .tak have issues being tranferred. I obviously don't need picture taking up my phone space, so their failures are ok to me. I am using Android v1.4.1 version now. 

Re: Is it true that v1.4 can't even handle .ape?

Reply #6 –
Quote from: Supermansaga on
I have been using FlashFXP client 5.4.0 build 3970 at https://www.flashfxp.com/download to transfer. Only .jpeg, .png, .ape, .tak have issues being tranferred.
I'm pretty sure Peter will test it to fix it, since other clients might trigger the same problem.
Nonetheless you might want to consider making the switch to a client that's  still actively developed (last update is from 2017), like WinSCP, Filezilla or Cyberduck.
 

Re: Is it true that v1.4 can't even handle .ape?

Reply #7 –
Tested FlashFXP, found some other curious behaviors that need looking at, but APEs and TAKs work fine.

This looks like another case of Google's multimedia access privileges.

Please MAKE SURE that foobar2000 is given "full disk access" permissions. Not just "read media" or "read music" or whatever they call it. Failure to do so causes other types of files - not recognized by Google as music - to be HIDDEN from foobar2000. This INCLUDES album cover pictures. Yes, they're this stupid - a music player can't see folder.jpg without also declaring itself as image viewer.

Alternatively, use "foobar2000 music folder", it's inconvenient to some extent as other file managers can't access it - but it dodges all issues with Android's mass storage access.
Microsoft Windows: We can't script here, this is bat country.

Re: Is it true that v1.4 can't even handle .ape?

Reply #8 –
Quote from: Peter on
Tested FlashFXP, found some other curious behaviors that need looking at, but APEs and TAKs work fine.

This looks like another case of Google's multimedia access privileges.

Please MAKE SURE that foobar2000 is given "full disk access" permissions. Not just "read media" or "read music" or whatever they call it. Failure to do so causes other types of files - not recognized by Google as music - to be HIDDEN from foobar2000. This INCLUDES album cover pictures. Yes, they're this stupid - a music player can't see folder.jpg without also declaring itself as image viewer.

Alternatively, use "foobar2000 music folder", it's inconvenient to some extent as other file managers can't access it - but it dodges all issues with Android's mass storage access.

Thanks. The "permission" is grayed out w/o letting me specify which kind of access I can grant it. Currently it says, "no permissions requested." And I'm on Android 14 for Google Pixel 7 Pro.