1. Just name the save "sound.bak" or something. Really simple but also very easy to "crack"!

Just mask it as an asset exploting a file format which allows putting more stuff at the end of the stream while regular file viewers will ignore your save data (i.e. png, jpg, pdf) like AngeCryption does (see slides).
Just make sure you don't really depend on that asset in case the file saving goes corrupt.

2. Save the data so some silly folder like "C:/appdata/flashdata/fakecompany/sound.bak". But ugly to create folder on the users computer and what if this folder is cleaned out (since its not supposed to be affiliated with the game)? Then the user will loose the progress.

If you do that, your program enters malware territory.

3. Save a timestamp to the savefile and keep a registry of the timestamps somewhere. If the savefile is replaced they will mismatch and you can refuse to load that savegame. But if the player backups the registry then? Which means i have to "hide" the registry file as well.

What happens if the clock goes kaputt? Quite common if the battery died. You'll just annoy your users.
Timestamps aren't reliable.

Also be aware that the process of safely saving a file (that is, following good practices) inherently involves performing an internal backup: (assuming no obfuscation) You first rename your Save.dat as Save.dat.old; then write your new Save.dat; and finally delete Save.dat.old
If the system crashes or power goes off, you first check if there's Save.dat.old and verify Save.dat is valid and doesn't crash if loaded. Once Save.dat is known to be ok, delete Save.dat.old; otherwise delete Save.dat and rename Save.dat.old as Save.dat
This way your user won't lose their entire progress, just the last progress they did (the power went off while saving... after all).

Take in mind that solutions that rely on writing to two or more locations to verify the save hasn't been tampered; you have to be very careful that writing to all those files ends up as an atomic operation, otherwise your "anticheat" technology will turn against your honest users who just experienced a system crash or a power outage and now have a valid save file with a corrupt verification file.

Why prevent cheating on single player games? Cheating is part of the fun. Otherwise TAS Video communities wouldn't prosper.

I'm in the camp that says its not worth your time to do something novel (some new kind of 'protection' scheme) or overly 'clever' (and disrespectful, like hiding files in unexpected places on a user's machine, especially silently).

If you must do anything at all, do something with standard tools and practices. Yes, the experienced cracker will get around this still -- the experienced cracker will get around anything you throw at them. So it follows that the best use of your time is to reasonably thwart the casual cracker (they kind who seeks out a save file and makes his or her own backup, or might open ASCII save files in a text editor and try to manipulate them) with a minimum of effort using standard mechanisms.

For example, if you put a binary-formatted save file into a password-protected.zip archive (and maybe that password is a hash of the user's "product key" or their registered email address, and named it something innocuous like "metadata_db.bin", no casual cracker would be likely to get around it. Anyone who has the skill to determine what you've done and extract the password scheme from your executable is not a casual cracker. Now, once even one real cracker takes an interest in defeating you, they'll probably release tools to automate the process if your game is at all noteworthy, and once that happens the floodgates are open to all, but at least the less-scrupulous players will have to seek out the crack tools first -- and I guess that if causing them that small inconvenience helps you sleep better at night, go ahead, just make sure the sleep you gain pays dividends to whatever time and sleep it cost you to implement the scheme in the first place.

[EDIT] Thinking about it more, even what I described, because of where the metadata_db.bin file would most likely be located this is still somewhat unscrupulous, because it wouldn't play well with the way that user might try to backup their data. To be a good citizen on your users machine, and you should always strive to be, you should put their save files in the place designated by their OS, not just next to where they happened to install it (this follows for user and global configs, screenshots you allow them to take, etc, too). For user configs and save files, this is well and narrowly defined, on something like linux, its well defined but I believe more broadly. On Windows, if you play by the rules of where certain kinds of data should go, a users can use the system backup and restore or migrate their user profile to another PC, or move their data to the newest operating system, and they should be able to expect that everything just works, even if they have to re install your game. You should try to make sure they're not disappointed. You can still put it in a password-protected zip file with an innocuous name if you like though (but the strange name probably less indiscreet here.)

If you're going to implement something like this, you'll want to keep the following in mind:

- Unless you use a server, it's going to be circumvented. You should therefore expend the minimum amount of time and effort to get the job done, and ensure you're not negatively impacting the experience of non-cheating users.

- Players like to and should be able to back up their saves (to move to another device, reinstall Windows, for peace of mind, etc). Your solution should allow this.

- If your game doesn't work for players you may attract bad reviews, etc. Your solution should not trigger accidentally, and must not look like it could be a bug if it is triggered.

 

Keeping the above guidelines in mind rules out most of your original ideas for violating at least one. I definitely wouldn't go hiding things around the player's computer.

I would suggest the following:

 - Apply some VERY basic encryption  (ROT13, XOR, etc.).

- Store the save in a protected archive format, but still name the file "savegame" or similar to allow backup.

Job done, casual fiddling should be deterred.

Hope that helps!