Caching streamers save the track to cache, whether that is ram only (ie, innuous pulse mini uses 2gb Ram for this when playing from a service, or a streamer that uses a local drive for caching, ie, an ssd or a card to save the cached track to “offline content” which is configured in the app. Where there is no local storage for the app, qobuzz/tidal to use, you cannot save the cached stream long term as offline content.
Where there IS local storage (playing on phone or ipad, uses that device’s storage for “offline content”), of whatever type, to use, there is a setting to save streamed content locally as offline content. That content is exclusive to the app. Or you can just download tracks as files that can be played through the streamer itself then through the dac.
So a service such as tidal/qobuzz can do one of three things, caching to ram, saving cached to ram track out to disk as offline content, OR saving a downloaded file out to generic storage where any app that can read the format can use it. (For example stuff downloaded from, ie hdtracks.. I have yet to try the qobuzz download to see if those are only allowed to be played by qobuzz app)
The error checking for “streaming” happens against the incoming data that assembles into the track in cache. If there are too many errors, the track “buffers”, ie the system requests that portion of the track that failed error correction, to be re-sent and wats for an error free response. If that happens with too many parts of the track, or there is a continuous, short term, issue with the connection, the entire track is requested to be sent again.
This is evident on an unstable internet connection when requesting a service’s app to play a track. The download will start, and possibly start to play, then the bar showing the track’s progression will start again, playin the track either a few seconds for a few attempts, then it will start from the beginning, lr it just resets and tries to re-transmit the entire track.
If the track is not able to be completely cached, error free, after a set number of tries, the app will end its attempts to play that track. If you have another track request queued, the app gives up on the first and moves on to the next queued track, else it just stops attempting to play anything.
Enough with arguing jargon already, please. Whatever the precise terms are, this is what I observe in real life as a rural customer with crappy internet. Whether you want to refer to the saved tracks in the “offline content” for the app as “saved stream”, “saved cache” or “downloaded” doesn’t matter to me. Purchased and downloaded tracks serve me better for hires tracks, since I can get an entire file, and use with any playback system that can read flac, eventually, without the streaming app deciding there have been too many failed attempts and quitting on the track. Successful streaming for me is usually limited to cd quality, except on days when even that is failing.
ALL Streamers “cache” or buffer each “streaming content” object and perform error checking on the incoming packets. Period. What they do with that successfully received track in buffer or cache, and the process for error check fails, is a function of the service and what configs you set/can set, for the hardware running the interface to the service.
Downloaded tracks don’t buffer or cache as they are not “streaming content” but whole files and are not, usually, tied to a specific service to be able to play back and have a more robust, seemingly, process for getting a whole, error free, file.
