At least mp3, that is MPEG-1, Audio Layer 3, is divided up into "frames", small chunks of audio of specific length as stated by the bitrate of that frame. You can create an index of these frames and then seek in the audio file to the desired location. Alternatively, you can just guess the location of the chunk and start reading a bit before it and a bit after its estimated size - the MPEG stream contains marker bytes (ff fe I think) that will allow you to resynchronize to the stream. I'm not aware of any time code in the MPEG stream, so I recommend going with the separate index to reduce the webserver traffic. Maybe consider even adding an external API to request a certain time - seeking on the server is likely faster than requesting parts of the file via HTTP Range headers and hoping you found the correct offset.
But for doing sub-second exact cutting (or playback), you will need to implement a way of seeking in the decompressed stream as well, because each frame represents a "large" amound of sound. Maybe your playback libraries can start playback in the middle of a frame (after they read and discard the first part of the frame).
