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: file type conflicts? .AFC (Read 5186 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

file type conflicts? .AFC

Hello. First of all, sorry if this has been answered before, but I did some searching arround and couldn't find anything.

Recently I'm having some trouble with AFC files in foobar. I'm talking about a streamed audio format used in videogames that is handled in foobar2000 through foo_input_vgmstream. Lately the files just won't even load into the playlist, and after looking arround I think I see what the problem is.

It seems that the afc extension is also used by some types of AIFF files, and I presume that foobar now supports them through foo_input_std, which I guess is given preference in case of such conflicts. Since these AFC files surely have nothing to do with the AIFF the standard input expects, they are ignored.

Assuming this is so, is there a solution for resolving the conflict?

If not, I'd like to request a functionality for the user to chose what filetype is handled by what plugin. I guess input plugin are expected to declare the file extensions they can handle, so having a tool for managing overrides would be really helpful, specially if it can find conflicts and allow the user to choose.
Would also be useful to have an optional interactive override prompter. In the override manager you would select the default plugin to handle a particular type, and then a behavior selector with up to 3 options. [always use default] [always prompt] [prompt only if playlist is flagged]. This third option would be accompained by a flag for playlists to enable interactive selection in conflicting types, where non-flagged playlists would just use the default.

Well, it may be an over-engineered solution for something nobody else seems to have trouble with xD. I just wanted to explore all the related usability aspects. The feature's final form (if it's ever implemented) could be much more bare-bones. As long as you can somehow override format-to-plugin associations, the job's done.

Without regard to this little problem, I want to say thanks to the respective authors of this great player and all the plugins for all so far.

Regards.

file type conflicts? .AFC

Reply #1
UPDATE
I have sort of solved the problem. This is what I did:

Since I deemed the believed conflict in file usage between foo_input_std and foo_input_vgmstream as responsible for my videoga-originated, non-AIFF *.AFC files not playing, as I guessed it was the standard input trying to open them as AIFF and failing, I tried something I expected to fail, which was temporarily removing foo_input_std.dll (actually just renamed to ".dll_"), which, of course, as expected, caused foobar2000 not to load and throw an error warning.
Interestingly, though, after renaming it back and opening foobar2000, my AFC file did play. I assume that by loading foobar without the std input, and then restoring it next load, caused the filetype-to-plugin association table (?) to be reorganized in favor of vgmstream, as, in this case, std was now the "new kid in town", unlike before, where it was one of the "founders" lol.
I then also tried to uninstall vgmstream and then install it again, which, unexpectedly, didn't make my AFC files unplayable again.
But now, each time I load foobar2000 the same afc file, be it opening it again or just replaying it from the same playlist, may or may not work. Some times it does work, some it doesn't (at least it works SOME times now, as opposed to before, when it would NEVER work xD), so I have no idea what's up. Perhaps the internal file association table is redone each time you fire up foobar, and it's just a matter of chance which plugin may be assigned an extension it disputes with another plugin?

Well, if anyone can explain to me what causes this, I'd be happy to understand it.

Apart from that, I'd like to expand my feature request to have some context info on what plugin is being used for a file, like having that information in the properties window and/or an title formatting field such as %fb2k_component% that reports the component being used for that file, in addition to the method for manually resolving conflicts.

file type conflicts? .AFC

Reply #2
i believe all components are loaded in a random order. this is done to prevent people making components dependent on others ones being loaded before/after it.

file type conflicts? .AFC

Reply #3
i believe all components are loaded in a random order. this is done to prevent people making components dependent on others ones being loaded before/after it.

You're right. Additionally I remember when Peter said that in situation when certain file type is supported by 2 or more components, there is no mechanism that enables chosing that given file type will be opened by certain component. Peter said that "this is random by design".

file type conflicts? .AFC

Reply #4
If the file isn't AIFF, the standard AIFF decoder should be gracefully failing to decode it and letting other decoders attempt to open it. I'd like to have a look at a file where such problem occurs - you can post one here. Thanks.
Microsoft Windows: We can't script here, this is bat country.

file type conflicts? .AFC

Reply #5
Oh, but it is AIFF. It's just a compression type the standard input doesn't understand.


file type conflicts? .AFC

Reply #7
Found the problem. It's not an AIFF-C file, but GameCube specific format with no identifying header, known only because it has a .afc file name extension. The standard AIFF-C input is apparently rejecting it with bad data instead of unsupported file when it sees no AIFF signature.

file type conflicts? .AFC

Reply #8
Bug fixed for the next version.

The standard AIFF decoder wasn't rejecting the file (which is obviously not AIFF) early enough to let other decoders attempt to open it.
Microsoft Windows: We can't script here, this is bat country.

file type conflicts? .AFC

Reply #9
Thank you