Tired of having to sort through all of those .mp3 folders? Copy them all into one directory using this command!For Linux/Bash Users only!

Open a terminal and enter this:

find /home/USER/Music -name '*.mp4' -exec cp --backup=numbered -v -t /home/USER/NEWFOLDER/ {} +

This command will need to have the USER field replaced with your username, and also have the NEWFOLDER field replaced with the desired folder name.
This command will find all of the .mp3 files in the users Music folder and all it's subfolders, then execute a copy command which will place them all into one output folder called "NEWFOLDER" and give all duplicate files a name enumerated by a number in the new filename to distinguish them from one another.
For example, if the are three files with the same name, two of the will get numbers attached to the filename in numerical order. Ie. Music.mp3, 1Music.mp3, 2Music.mp3, etc..

**NOTE: Remember to change '/home/USER/Music' to match the location of your target files!

Setting up a Vmware Workstation with Spinrite in Linux:This is Experimental and only useful to determine if there is an error on the disk which needs to be fixed**

This is a question everyone seems to want to know so here goes the “light” version. This instruction assumes that you already have Vmware Workstation 12 and a legal copy of Spinrite in .iso format. Create a folder named '/home/USER/vmware/spinrite' and copy the Spinrite.iso into it. The purpose here is to use a Virtual machine to execute Spinrite without the need of another entire computer designated to the purpose of Data Recovery. This will also free up your production machine for other tasks. It's now time for you to know which device on your Linux machine that represents your USB drive when it is plugged in. Plug in your USB drive and open a separate command terminal. Enter: 'sudo fdisk -l' at the command line to list the currently mounted drives on the system and look for your USB disk. Mine shows as '/dev/sdb'. Remember this, and do not mistake your primary HDD! Make sure this is the device id of your usb drive! If your USB devices mount the same '/dev'sdb' every time then the rest is simple so here we go:

1. Run Vmware Workstation from the command line as root: 'sudo vmware'.
2. Create a new virtual machine and select “Typical” then click next.
3. Select “Use ISO image” and select the Spinrite.iso file to use a the source to install the Operating System. Note that there will never actually be an install of Spinrite so place the .iso inside the “vmware” folder as mentioned where it will stay permanently. Click Next.
4. Select the Guest Operating System as “Other” then select MSDOS. Click Next.
5. Now Choose the Virtual Machine Name as “Spinrite VM” with the default location of : “/home/USER/vmware/Spinrite”. Click Next.
6. Store the OS as a single file and the size will be .005 GB. This will create a 5MB disk. That's all we need! We are going to delete it anyway because this is just to create the VM. Click Next.
7. Uncheck the “Power on after Creation” checkbox, and click “Finish”.
8. Now edit the Virtual machine settings. Click on the Hard Disk to select it then click the “Remove” button at the bottom of the screen. We don't need a internal HDD – unless you are cloning but I digress from this for now. Edit the HDD and click on Advanced to turn off "Write Caching". Also remove the sound card, network adapter, floppy disk drive, and don't forget to turn off the “3d Support” under Display, and give this VM 1GB of RAM!
9. Now click the “Add” button and select “Hard Disk”. Then choose “SATA” and click next.
10. Select “Use a Physical Disk” and click next.
11. Remember your device id? Mine was '/dev/sdb' so I will use that and ever this into the “Device” field, and select “Use Entire Disk”. If you see a warning that you need to run as root you must STOP HERE and start Vmware Workstation as root, then start again at Step 1! Click next.
12. Now you should be at the “Disk File” menu which asks you if you want to use the “Spinrite-0.vmdk” file to store the settings. You will accept the default here and click Finish.
13. Now when you Power ON this VM immediately press F2 and enter the BIOS of the VM, navigate to the Boot menu and move the CDROM to the first in the Boot Priority. You can also right click the Spinrite VM tab, select Power, then Power on to Firmware, and change the setting from there. Then press F10 to “Save and Exit”.
14. All done! Your machine should reboot at which point your drive should be accessible.*


Now whenever you want to run Spinrite on a disk you can run Vmware as root (or else you can't access the '/dev/sdb' device!). Do NOT start the Spinrite VM yet, plug in your USB HDD, wait for the HDD of the Virtual machine to detect the USB Device (It will show a HDD when the USB is plugged in, no HDD when it isn't plugged in) Now start the Spinrite VM and fix any disk you want without any extra hardware!

*Note that this may not work on some DRV or XBox partitions either because I just have not figured it out yet, or Spinrite has an issue which prevents this from working properly. *UPDATE Spinrite has an 1TB limit as of Spinrite version 6.0.

Critical UPDATE**:
**I have learned the hard way that once you install a Hypervisor on a computer, NEVER install another Hypervisor on the same system at the same time. I tell you all this just in case this type of stuff happens to you, and the symptoms I have described above matches your symptoms and you have been unable to use Spinrite to repair disks shortly thereafter the install of a second Hypervisor. This diagnosis also comes to you after not being able to repair disks for two years without any reason as to why it ceased to function. Without any notice the second Hypervisor "hooked" the Kernel thus overwriting a hook from the previous Hypervisor leaving the system crippled without any way of knowing or diagnosing the cause. I had to put 2+2 together. However since I had determined that the new Hypervisor was superior, I stayed with that for a long time trying to fix the problem. I never did. I found out because I went back to the old Hypervisor (just to stay familiar) and Viola! I could again repair disks! It was something I should have seen before the problem became muddled by time, and other installs. I had no reason to think that I should test the software against a new VM, and could think of no reason as to why it wouldn't work like usual. I almost downloaded a new copy of Spinrite thinking maybe mine was faulty somehow, but I figured it out and I still have the prestigious download count of "1" and wish to keep it. The above mentioned issues are the effect of the bad/unrepairable Kernel API/Hook that was made faulty by installing a second Hypervisor before completely uninstalling the first, AND REBOOTING. Even then, uninstalling and rebooting is not a guarantee that the old Hypervisor Hooks aren't still there and waiting to become faulty the moment you decide to switch to a different company for Virtualization. You may be able to switch back to the first hypervisor to get things working again, but be prepared for an full reinstall of the OS to fix the problem.