You can't change it in place, as far as I know. You may be able to do it without finding another Tb drive to copy the data to while you rebuild the filesystem by a round-about method:
- shrink the current filesystem as small as it will go and drop the length of the partition accordingly
- add a second partition in the newly freed space
- mount both, and move as much over to the new partition as you can
- shrink the first partition again, move the new one down the disk and grow it to fill the drive and repeat step 3
- you might need to repeat step 4 once or twice more depending on how full the original filesystem was to start with
You can do all the above manually with fdisk, resize2fs and related tools, or with parted which is available in most distribution's repositories and as a Live CD. gparted it probably the safest option by far unless you are very familiar with the manual tools already.
But major filesystem move/resize operations like these are the sort of thing I always take good backups before starting, because if anything goes wrong you could kill everything on the affected filesystem(s). So if you are healthily paranoid the above does not remove the need to find somewhere to copy the data too while you reformat/rearrange... Though if most of the data is replaceable, by re-downloading music/video content and such, you could backup the most important stuff and take a chance with the rest.
As an alternative to reformatting/rearranging the drive now you could run a small Linux VM (with vmware or vbox), attach the USB drive to that, and have it share the data to the host (Windows) OS via Samba. This is inefficient and less convenient, of course, but may well be efficient enough "for the time being" until you sort or more permanent solution like buying a new drive to reformat and move everything onto and it is certainly safer than massive filesystem operation on data that you do not have backed up. You do not need to allocate much resource to the VM, I'm guessing a server install of Ubuntu or a base install of Debian would happily run such a Samba share in 128Mb of RAM or less and would not need much more than a single Gb of disk space (in fact, it may only take a couple of hundred Mb, if that) on the host machine.