in_cube makes winamp ignore the rest of supported formats? by Ikkutebayo at 10:47 AM EDT on April 8, 2007
It's funny, every time I install in_cube, the rest of audio formats (mp3, wav, midi, etc...) won't show normally in the winamp window with types supported by in_cube (dps, acx, hps). I have to switch from "Sound types" to "All files" to actually see them. It gets a bit annoying after a while... Is this a problem of mine or it's common?
Common problem by anewuser at 3:07 PM EDT on April 8, 2007
Hi.
This is a common issue. A quick search on the Winamp forums brings many hits about it. A OS limitation in the 'Open File' dialog, (limited to 260 characters in lenght).
For users with many input plugins this in an annoying issue (to have to go to add->select all files, and selecting the files)
Maybe hcs could add one extension, and be more verbose in the file properties within Winamp?
anewuser ps: you'll need to disable some lesser known|used file associations, btw.
It'd be extremely useful if in_cube's supported files could be all narrowed down to one file extension. The reason this is a problem though, is because to do this, you would have to create a container format. This container format could very possibly be like a xSF file. However, to create a container that's compatible to all the formats available is difficult.
Another very nice thing about a container format would be the ability to add tags. Also, for use in Rockbox, it'd make a port far more likely. HCS has said that one of the biggest things holding a port back is the sheer amount of filetypes that in_cube handles. If that could be cut down to one extension, then the port would be much more likely.
In other words, the issue of which you are concerned about is well known, but it's not a fault of HCS, or in_cube. It is fixable, through a workaround, but the workaround is difficult to implement. The idea of a container format has been floating through #usf for some time. However, no one has the time and skill to implement it.
Hopefully this answers your question adequately. Sorry to not have a solution for you at this time. Hopefully someone will be able to implement a container format, as it would be of tremendous use. Mouser X over and out.
the main thing is that if the structure used to hold the extensions (OS side) had been designed with a size member instead of just take the buffer and internally limit to MAX_PATH for the system (the 260 char limit).
the only way is to either have the location of the filters adjusted around, removed, or what is found to go past the 260 limit to be added as a second 'all files' option in the filter list.
i do vaguely remember someone saying there was a proper workaround but i can't find any trace of it (maybe on true NT based OSes this can be circumvented but i don't know for certain).
the best advice really is to remove the extensions that you don't need (i did have a mini tool which showed where things were cut-off at but the unicode changes since 5.2+ have most likely broken things i think for it)