What Happens If You Copy An Audio File While You're Playing It?

Comments

1. ► S3C

   Friday Nov/6/2020

   "Nothing?"

   on a well designed system, yes/usually.

   "Can it affect quality of the copy?"

   If the process is stopped or interrupted yes. Some algorithms for loading images and video involve 'copying' the contents to a local server, and 'decompressing' it to higher quality resolutions as more bandwidth is available or data is transferred. You might notice on video streaming sites, that lower bitrates are available initially, with higher quality options become available as more of the video loads. With images, some sites load at the full-quality image from top to bottom, opposed to starting with the entire image, with a blurry resolution to gradually filling in pixels. In some audio downloading apps of the 2000s, programs would download or generate the full length/size of the file, and slowly fill in the contents of the song. If your connection got interrupted, you might get the first and last 30 seconds of a song, with the middle being garbage bits. In gaming, the consequence is more obvious- you miss frames and movement/actions are laggy.

   "Can issues occur?"

   They can always occur. On well designed systems, theoretically no.

   "Does it depend on the player - if it caches the file while you're playing - and as such you actually don't copy the same file that's playing?"

   As a bit of an aside, there are two types of 'copy' operations in the computer world- soft/shallow and hard/deep. That is not a intentional pun, but lolz where had.

   This blog refers to hard copies, you have a block of 1234 bits, the operating system allocates a new block of 1234 bits, and pastes the exact contents of the original block there.

   A soft copy would be a link that you put on your desktop. Or a shortcut on the start menu or icon pinned to your bottom panel. The only memory here is the pointer, which says 'hey look here! the data you want is at at this memory address'.

   Now whether the program caches the file (a deep copy) or reads it from memory shouldn't matter. If it's a pure playing operation, then the original audio file should be in a read-only state, meaning you can copy and play the file simultaneously and indefinitely, to what your RAM and CPU can handle. Now say you load the file in Audacity, you have an option of caching the file to a temp location (safe, but takes up more memory) or streaming it directly from the disk, and you choose the latter, a good operating system will lock the file from use from other processes when it's directly being operated on. In this case it doesn't really make sense to make a copy of a file that is actively changing, or conversely, to open a file for editing while it's being copied.

   "Is it a software or a hardware thing?"

   This question involves how programs load data and how Operating Systems protect/manage their files, so software.

   "Did copying audio files in use work with DOS. or even Windows XP?"

   audio didn't exist in DOS. it was just beeps and boops and crappy soundcards. but the underlying principles have been the same even in the earliest computers.

   "And does it depend on the format? Can you copy some but not others? MP3 seems to work, haven't tried WAV, FLAC, APE, M4A...."

   the copy operation is an OS command and knows nothing of the format, which is program specific. A few Windows exceptions includes executable and registry files such as .exe and .dll. So no it shouldn't matter.

   "Internet didn't have the answer for this, so I'm just leaving the open question here.

   If you have the answer, do tell."

   These opinions are of my own, and do not necessarily reflect those of the Internet, and I make no claims of having the answer. But I do hope you derive some insightful insight from this post.

   Best regards in your thirst of knowledge within the digital realm,

   Dr. Sumir Thripi Chandra 'S3C'

2. ► Cyber

   Friday Nov/6/2020

   "Nothing?"

   Like a noob not differentiating between copying and transferring in my pondering above; not giving a thought as to the distinctions I do know of with said actions within different working environments. XD And now not actually being certain if I was testing with a file from one physical location to an entirely different one or actually just creating a new reference for said file locally... though maybe only Linux works entirely off of reference; Windows allocates bits even with copies, at least I believe I've read it was so...

   It seems, with Windows 7, that I can copy a file while playing without error. Yet if I try to export a new version via Audacity then the file is supposedly locked, and the file isn't overwritten. But... what does that really imply? Considering 'If it's a pure playing operation, then the original audio file should be in a read-only state, meaning you can copy and play the file simultaneously and indefinitely' does this imply both copy and play operation would usually cache the file in their own regard, as to facilitate concurrent operation? If you have a 4MB file, and open it in a hundred different audio players, would that simply put be +400MB RAM (excluding whatever overhead the players themselves have), as individual memory-based caches are used with each? If so then the simple component I've had all this trouble wrapping my head around with regard to this question would be: RAM...

   Did learn a bit with the bit bit! And copy method names! :D

   Progressive images, yes. It doesn't even take more file size to use that particular type of encoding. Wish more sites used them. Seemed more common back in the day. Also interesting with regards to video, have noticed but not considered the technical aspects of.

   Full-length file allocation is still in use with download managers and the like today too. Useful for making sure you really have enough space whilst downloading very large files!

   Also did not realize you could simply stream audio files from their original source when working with Audacity... dragging them onto the interface seems to copy the file by default, as deleting the original doesn't remove said instance. Opening project file on another computer: no problem either. Fun note though: if you export a file with an identical name, Audacity apparently first exports a new file with a -0 appended to the name, then deletes the old version, then renames the new version to the original. Maybe it's common procedure but I've never seen it in action the same way with other software. Suppose most probably use a hidden TEMP folder somewhere.

   Were you using DOS back in the day btw? Explored old OS:es later on in life? Or just read up?

   Do thank you for your guidance Dr. Sumir Thripi Chandra 'S3C'! Very informative indeed.

3. ► S3C

   Saturday Nov/7/2020

   well I believe by default, Audacity projects store the audio inside the project file itself. This isn't the norm and certainly isn't space friendly, but it's optimal for portability.

   yes...been using DOS before the Windows days, exaggerating some about it's (latest) audio play capabilities but in the 80s and early 90s...the quality was very bad

4. ► Cyber

   Saturday Nov/7/2020

   Wait wait, default but not norm? Not norm with music software overall, but norm with Audacity? It is pretty practical for that yeah.

   Mmm, getting a sudden urge to install it on some old laptop and hear what that might've sounded like. .) Won't follow through on that though... right now. Time and all. Was that the first OS you used? Going even further back with Commodore and whatever alternatives were available back then?

The Comment Form

Your email address will not be published. Required fields are marked *

Comment *

Your email is saved only to approve your future comments automatically (assuming you really are a human). ;) It's not visible or shared with anyone. You can read about how we handle your info here.

Name *

Email *

Website