Q:

Can I JOIN a table based on an SQL if-statement? 

I have three tables being used for this problem: songs, blacklist, and whitelist.  The songs table has a column named "accessType" which stores one of these four values: public, private, blacklist, whitelist.  I'm trying to fetch a list of all the songs a user may access.  The first condition is that songs.accessType ! = private.  Here comes the tricky part: if songs.accessType = blacklist, I need to check that the user's ID is not within the blacklist table.  Similarly, if songs.accessType = whitelist, I need to check that the user's ID is within the whitelist table.  It seems to me like I need to JOIN the blacklist and/or whitelist table under certain conditions, but I have no idea if this is possible, or even the right approach.  Any help is much appreciated, thanks! 
Here's an explanation of my table schema:

songs: id, name, acessType, userID
blacklist: songID, userID
whitelist: songID, userID

Edit
Here's a breakdown of the foreign keys:
songs.id -> blacklist.songID
songs.id -> whitelist.songID
songs.userID -> blacklist.userID
songs.userID -> whitelist.userID
Ravish's answer is working, but I'm interested to see why people are saying it's not efficient as possible. 
Also, what is the significance of the @ symbol before userID?  I replaced @userID with ?  and I am binding parameters to the query. 
@Workshop Alex - private songs should not be included at all. 

A:

SELECT * FROM SONGS s
WHERE
   accesstype='public'
   OR (accesstype='whitelist' 
      AND EXISTS (SELECT null FROM WHITELIST wl WHERE 
          wl.songid = s.id AND wl.userid=s.userid))
   OR (accesstype='blacklist' 
      AND NOT EXISTS (SELECT null FROM BLACKLIST bl WHERE 
          bl.songid = s.id AND bl.userid= s.userid))

If accesstype=private, it won't slip through, there's no need for an additional clause. 
I chose using correlated subqueries because they are, in this case, more readable than filtered left joins.  Perhaps MySQL is a tiny bit less efficient at them, but one should not make decisions about design based on minor temporary limitations of the query optimizer, unless the performance difference is absolutely critical.  Perhaps the next version of MySQL will be even faster with this than a left join.