That depends upon Polish copyright law. However the EU harmonisation of copyright law ensured that all Member State’s legislation provides similar protection in this respect ( I am overlooking Poland’s current impasse over the primacy of EU law). So from a strict point of view you most likely are infringing copyrights in both sound recording and musical work. However you should regard this as a technical infringement only. The rights owners ( record companies and music publishers) would not find it economically justifiable to pursue a claim against you in this respect and, I suspect, would have no desire to do so as it would likely cost them more in legal fees then they could recoup from any damages awarded. The private making of single copies for technical reasons from a copy legitimately purchased by the copyist is unlikely to attract the rights owner’s attention. I believe that the International Federation of the Phonographic Industy ( IFPI , the international trade body of the record companies) has made a statement to this effect but I do not know the music publishers’ official stance.
Of course next time you download any 24/192 file you should do this as AIFF and not FLAC. BTW , as I mentioned before you likely can go back to the vendor of your 24/192 FLAC file and download it again as AIFF without having to buy it again. No conversion issues then talhough the size of the download may create problems in itself.
I think AIF files use ID3 tags to store metadata whereas Flac files use Vorbis comments. I have seen huge metadata blocks in Flac files (downloaded from HDTracks), much larger than actually required to contain the album art. One would think that removing the album art would remove the metadata block containing it but it doesn’t and player software has to read through the whole block to see if there is anything there. The metaflac command line utility can show the metadata blocks in Flac files and can be used to remove large empty album art blocks.
The workaround that James proposed should work in all cases as it does two things to alleviate the problem: removes any large Flac metadata blocks and removes the need for the player unpack the Flac data. While neither of these tasks should be a challenge for any modern processor it appears that DCS may have dug themselves into a bit of a hole with their player software design when dealing with 192/24 files.
To expand upon this a bit further, and this is speculation on my part based on James’ explanation of the problem, the Bartok manual and my own development of a software player over the last 17 years: I think the issue is that the DCS player does not look at the next track to play in advance but waits until it is due to play to read the metadata and deal with it. It uses a buffer to facilitate this but that buffer appears to be a fixed size. The manual says it is .72 seconds for 44.1k files down to .16 seconds for 192k files. With a high sample rate Flac file with an abnormally large metadata block it probably simply runs out of time to process the metadata before the buffer empties leaving silence until the flow of data resumes.
IMO a better design is to have a buffer that is larger for higher sample rates so that the buffer time remains constant and better still to do all metadata processing for the next track in advance so that there is very little to do on track transition. To retrofit either of these options to the DCS player would be non trivial since they are fundamental parts of player management and may not even be possible if there are memory constraints.
If preprocessing of the next track were implemented in the player this could also fix the DSD playback issue and facilitate implementation of gapless playback for UPnP controllers (the UPnP specification provides an optional next URL command which is not currently implemented in the DCS player).
Any such changes would require a very significant amount of testing and I suspect they will not happen soon and possibly not in the current generation of players.
Unfortunately that is not the case. It will work with locally stored files where they are accessible for conversion to another format. However , as I have pointed out, this is of no use where the issue is arising during the play of internet streamed hi-res FLAC files. There is nothing that the listener can do in this respect. This is becoming an increasingly pertinent issue as many now use streaming for their primary listening and some have even gone so far as to abandon local file storage.
I find your points very interesting and probably have to agree that the solution suggested by you would:
Yes you are right and I should have been clearer in what I meant by “all cases”. I actually meant to say all files stored locally where, as you pointed out, conversion to another format is possible.
I have never actually encountered the problem with my 192/24 local files possibly because I always use metaflac to remove the metadata blocks and associated padding and then replace it with a reasonably sized cover image using dbPoweramp.
I tested a couple of 192/24 gapless albums from Qobuz and did experience the gaps that others had reported.
Thanks Erno, I stand corrected… I think (when you look at the available User-space memory managed by Linux kernel on the Streaming board, it seems to be just under 256MB).
After this status, the rest of the software is loaded on the physical 500MB memory. It seems to have 12 partitions. How they are getting filled by the FLAC decoding process I, of course, do not know.
Whether you don’t look at it, 24 / flac 192 audio material, is reproducet with non gaples the fact remains that the DCS devices process it with errors. The proposed solutions are effective, but require certain knowledge and efficiency in using the conversion software and its purchase. Since the problem is playing streaming content in 24/192 flac resolution, it means that the problem lies in the way such material is processed by DCS devices. Service providers streaming the flac 24/192 format and putting large image files inside the uploaded files probably have the right arguments to do this. The technical description also shows that there is so much memory in DCS devices that the flac / 24/192 processing should not be a problem. I do not have any material played gaples in the resolution of 24/384 flac and yet the manual says that DCS supports files with this resolution, but it has not been added that after appropriate preparation … It is always the case that correcting one error can generate another. I am ready to try out the beta software which will include a fix for this bug.
Apologies for the delay in coming back on this one folks. Could someone provide an example of an album which is experiencing gaps between tracks on Qobuz? Despite best efforts, all the 192k albums I try seem to have hard finishes to tracks so no overlap to hear gaps in.
James the album that started the thread is a fair choice : Bill Evans Trio " On a Friday Evening". Although the track indicators are at the conclusion of each number if you listen to the album in a resolution lower than 24/192 you will hear that the audience noise continues ( quietly) through to the following number (i.e. played gaplessly). I would do this first to establish what should be heard. Using 24/192 instead you will hear a break in the audience noise as a brief gap is inserted ( can sound as if a click or tick is added as well).
It uses a buffer to facilitate this but that buffer appears to be a fixed size. The manual says it is .72 seconds for 44.1k files down to .16 seconds for 192k files. With a high sample rate Flac file with an abnormally large metadata block it probably simply runs out of time to process the metadata before the buffer empties leaving silence until the flow of data resumes.
I suspect this is the same issue with fixing the Rossini issue with dropping the first .84 second of a .DSF track when it switches from PCM to DSD; I suspect it drops the data because it doesn’t have buffer space to store the data while it’s examining the data to ascertain whether it is PCM or DSD, something every other PCM/DSD DAC does as a matter of course.
I don’t think dCS ever thought there would be a need to buffer up to a second of DSD 128 data before sending it on through the DSD decoding mechanism, and all the Rossini can do is drop it on the floor once it realizes the datastream isn’t PCM.
Lack of buffer space would apply to both these situations, even though the buffer would only need to be a few MB in size.
The buffer you can toggle seems like an obvious candidate, but it may not be large enough.
Reading about the problem with switching from PCM files to DSD, I thought to myself if this problem is not related and has the same reason. It worried me, however, that in such an important product as the Rossini it had not been fixed for over a year.
dCS updates have always been slow in coming, and I’ve been willing to cut them slack due to COVID, but I suspect that promised Rossini update will not ever actually come.
Perhaps it’s paranoia, but it’s inevitable Rossini will be replaced and dCS never updates discontinued products.
Also, to clarify my earlier comment about buffering, what the Rossini would need to do is buffer data as it comes in while it determines whether the stream is PCM or DoP and if it is DoP it would need to start DSD playback with the first bit received and forever lag behind what was just received.
Instead, when it realizes it’s DoP it decodes bits from that point as DSD and the data received earlier is just lost.
I currently have a similar problem with files with a resolution of 24 / 352.8 (DXD). The beginnings of the recording are cut off, maybe 1s. It was harder to catch because it’s a studio recording. Of course my Bartók has all the latest updates. It seems that the DCS devices have some problem with the dense files because between DSD128 recordings I hear a slight click in the speakers.
Best Regards Robert
The problem concerns Flac 24 / 342.8 and DSD128 files stored locally and played from my Qnap server with Minim Server (latest version) installed. Lan connection, DCS Mosaic used to control file playback.
(when you look at the available User-space memory managed by Linux kernel on the Streaming board, it seems to be just under 256MB).