Skip to main content
Topic: foo_sid (Read 65957 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: foo_sid

Reply #125
Any version from v1.18 to v1.34 is guaranteed to be unstable in multi-threaded use. Either use v1.35, the latest, or if residfp is too slow for your processor, downgrade to v1.17. That's from 2010, hope you can find a build somewhere.



Re: foo_sid

Reply #128
Everything is working using the latest versions.  Thanks again Kode54 and Thundik81.



Re: foo_sid

Reply #131
Hi, I'm not sure if this is the same error as FWaldek is reporting above, but I thought I should report it anyway.  For whatever reason -- unfortunately I didn't keep track of what caused the change -- I can't play SID files anymore.  They all just yield the error "Unable to open item for playback (Unknown exception):", followed by the filename and track index within the file.  As best I can tell the problem really is specific to SID files; other game music I have works fine (including other ones with multiple tracks per file), so that would seem to point to foo_sid.  (Or perhaps as you say one of its libraries, but...)

I've updated everything to the latest version (fb2k v1.3.17, foo_sid v1.36) so updating it is not the problem.  FWIW I am not running it under Windows but rather under Linux (Mint 18.3) via Wine (1.6.2, I guess that's not the latest version) but I would be seriously surprised if that were somehow the problem.  Like I said I wish I'd kept track of what update might have broken it, but I didn't, sorry, so I can't tell you that.

Thank you!

Re: foo_sid

Reply #132
Recently several users (including me) had problems due to the amount of plugins (mostly input related) used in foobar. Reason for this was the fact that some plugins after recent updates became multi-dll. And there is a limit of dlls that can be loaded into Windows app (128 pcs). Check if problem persists after temporary removal of for example 10 other plugins (starting form input plugins for other file types).

Re: foo_sid

Reply #133
OK, I tried removing a bunch of decoders (and a few other components) that I wasn't using (and then reinstalling foo_sid for good measure); this had no effect.

Re: foo_sid

Reply #134
Updated it after almost a year, with more updates from sidplay-residfp. Maybe building it with v141_xp SDK fixes your problems?

Re: foo_sid

Reply #135
Thank you!  Unfortunately this had no detectable effect.  I wish there were some more informative error message I could report but it's still the same.

Re: foo_sid

Reply #136
Oh, right. There is a problem. I use MSVC's mutex and other threading objects in the sidplay library to synchronize object initialization. This stuff was not working under Wine until around version 2.0 or so. Prior to that, it would just throw exceptions on object creation, due to missing API in Wine itself.

E: Checked my own bug report against Wine. It was stubbed and minimally worked around by 1.7.38.

Re: foo_sid

Reply #137
Oh huh.  So it was a Wine problem.  Guess I was pretty badly calibrated on how likely that was; I was all like, that seems pretty unlikely, because Wine has always worked so well with everything foobar2000, it's never been Wine before.  But OK.  Will try updating Wine and make sure that fixes it.  Thank you again!

Edit: Yup, updated Wine to 2.0.3, and now SID files now work once again.  Thanks so much!  And now I can go re-install all those other components. :)

Re: foo_sid

Reply #138
Several crashes having various situations this year. Crashed module: foo_sid; component versions: 1.41 and 1.40.
Rolled back to version 1.35. Using the player normally. Under observation.

According to crash report info, last time I had 215 modules loaded into memory. It is much more than 128, bit I don't believe that is the reason of the crash.

Re: foo_sid

Reply #139
Foobar2000 v1.3.13
Component: sidplay2 v1.41
Music: HVSC\MUSICIANS\C\Chiummo_Gaetano\Power_Ballad_3SID.sid

Or any other 3-SID piece from the same author. They all play in fast forward, saturate a thread of the CPU and cause buffer underruns. My old foobar 1.3.9 with sidplay2 v1.35 plays them at ~8% CPU load (32% of a thread), at the correct speed. Other SIDs don't seem to be affected.

Re: foo_sid

Reply #140
Sidplay doesn't support 3 chip files that I know of.


Re: foo_sid

Reply #142
It might now. I don't know. I also don't know how I should map a 3 channel file. 2 channel was easy because it could be left and right, but what about 3 channels?

Re: foo_sid

Reply #143
Yeah, it supports 3 SID songs, but I don't know how my component handles those.

I do know there is a crash bug with 8580 songs that I just had to fix. Apparently, in the two years since I last updated it, the filter curve option for 8580 was changed from hertz to a softness scale, to match the 6581 config. The new range is 0.0 - 1.0, with a default of 0.5.

Re: foo_sid

Reply #144
Hello, I downloaded the .sid files for Modern Love Classics by MultiStyle Labs from here: http://csdb.dk/release/?id=157489

They play fine in SidPlay 2.6 but they come up with a missing or corrupted file error in Foobar2000 with the foo_sid plugin.

Re: foo_sid

Reply #145
Are you sure you're using the latest version? And that the SID plugin is above any other possible .sid playing plugins, like zxtune?

Re: foo_sid

Reply #146
If one has songlength.txt loaded, could you add some option to write a lenght tag to the file?
I understand SID files are as unfriendly to tagging as every other format of that type is (For whatever reason, probably age) but M-tags and that newer external tags plugin both remove that limitation.
This is just so I could see the actual length in the playlist/total length of the folder.

Re: foo_sid

Reply #147
songlength.txt includes every file in the STIL. I do not plan to write a way to modify the STIL documents. Storing the length in the tag only makes sense if I also offer a means to edit the length in the first place.

Re: foo_sid

Reply #148
songlength.txt includes every file in the STIL. I do not plan to write a way to modify the STIL documents. Storing the length in the tag only makes sense if I also offer a means to edit the length in the first place.
Ah, makes sense.
I wasn't thinking about writing THE length tag, though- My guess in how this works is that when the file is playback you check its checksum against the database, right? In that case I understand why is that proper length is only displayed when files are played. Loading that on boot would be a bottleneck if there were a lot of songs.
What I was wondering is, to be more exact, if you could make another tag ($SIDLength or something like that) that the plugin checks for upon loading SIDs into playlists, which you could add a menu option to write- either from Songlength.txt or with an user-inputted duration. That should use way less CPU time than checksums, right?

 

Re: foo_sid

Reply #149
File inputs are discouraged from using the metadb to access "tags" that are "already read" for purposes like this, since those values generally aren't even accessible at the point where files are opened. Someone is welcome to point out how I'm wrong on this one.

Also, if there's a tagged length, it's supposed to display the length on open, not on playback. Even if there isn't a tagged length, there should be a default length. Lengths are not displayed for files which fail to open at all, such as broken files.

 
SimplePortal 1.0.0 RC1 © 2008-2018