So TCP is connection oriented. We have acknowledgments. If the
transmission is lost, we should be able to continue it.
"Connection oriented" does not automatically mean transfers using it can be resumed. "Connection oriented" simply means applications that use TCP can use it as a "pipe" - i.e. send messages of arbitrary length to the other side, and then TCP will make sure the message gets there (retransmitting if errors happen) in the same order it was sent. If a TCP connection times out because one side stops transmitting for whatever reason (i.e. they lost their Internet connection, crashed, etc.), a second TCP connection in and of itself doesn't necessarily know anything about the first one. The application software using TCP connections to transfer data on both sides would have to keep track of that and support that by starting a new connection.
But my problem is, when we are downloading a file such as MP3, if the
connection is lost, we need to download the file again. So then isn't
it using the FTP protocol?
I don't know why you are thinking that if something needs to be redownloaded that it must be using FTP. HTTP supports resuming interrupted downloads, but the server in addition to the client needs to support it. Not all clients and servers will support all features of all protocols at all times. HTTP for example - typically you can resume an interrupted download but some servers won't allow it.
Isn't it TCP? So if it is UDP, can you please explain what kind of
protocol is that? TFTP ? I have no idea.
The fact that downloads can be resumed or not has nothing to do with identifying the protocol. There are many protocols that behave this way, and just because your download behaved this way doesn't mean a specific protocol was in use.