Thanks James. Unfortunately the issue relates not only to local files but to hi-res streams @ 24/192 from Qobuz. In that case the suggested workarounds would not seem to be applicable.
Of course exactly how Qobuz streams the hi-res FLAC files within a limited bandwidth is not public information ( I assume it is some kind of adaptive bitstreaming). However is more than the front cover artwork included? It is certainly all that is displayed. Of course the size of the image is down to the record label who provide the original file to Qobuz. That would suggest that these are likely to vary substantially . If so and if this is the cause the issue it should also be inconsistent . However there are too few 24/192 files that play continuously across track boundaries to establish this.
Frustrating!
NB: For those with purchased downloaded 24/192 FLAC files where this issue is a problem just a reminder that most vendors will allow you to go to your account and “refresh” your download in e.g. AIFF.
However, since this affects the behavior of files from streaming music services, DCS’s decision not to fix this error, which is also known, in my opinion is ill-considered. It’s a pity and a big surprise.
Regards Robert Tota
Robert, to be fair James does not say that dCS have decided not to fix the issue, only that there is no anticipated timing on it. However the move from personal ownership of repertoire to streaming means that workarounds that only relate to local files become of diminishing significance.
This concerns me if the fix is at processor firmware level rather than an issue than can be dealt with via a Mosaic update. Without any plan to fix it and with the likely replacement of Vivaldi in the not too distant future it may never be fixed for owners of this flagship.
Sorry, let my poor English be my excuse. I hope DCS can find a simple solution to this error and it will be possible by updating the firmware. I am happy to take part in the tests of such a revised software version for DCS Bartók.
Thanks James. Indeed I just verified that the AIFF work-around does the job (and I see no downside to downloading any/all hires purchases in AIFF going forward.)
That said though, Pete’s right, it doesn’t resolve the issue when streaming from Qobuz via Mosaic.
Not a show-stopper for those of us who primarily use Roon/RAAT, but, like Robert, those dependent on the Mosaic Client can’t be too happy about the situation, especially given we’re seeing an increased number of 24/192 albums being released for streaming.
EDIT:
By the way, if anyone’s interested, gapless playback via Mosaic on local AIFF albums works just fine with Twonky and Asset UPnP servers, in addition to MinimServer1/2.
Thanks a lot for your support. Blind and partially sighted people do not really have an alternative to use the capabilities of their DCS devices. The Web Controller is just a substitute for the Roon functionality that does not give full control over the playback options. More and more material is appearing at higher resolutions. I think it will be a constant trend. “AIF” files are very large, which is important for their storage, especially those with the parameters 24/192. Concert albums or progressive rock albums are examples where we may have problems with their correct reproduction.
James wrote that the gapless playback problem was caused by embedded cover art files stored in flac files. To my surprise, when, as suggested, I wanted to remove the cover from the 24/192 album, it turned out that there is no cover there and there is nothing to remove. It seems that this is not a cover problem but the processing of flac 24/192 files by DCS devices.
Which 24/192 album were you looking at? I just checked my Bill Evans Trio “On a Friday Evening (Live)” FLAC album which has the problem; every track has an embedded 1024x1024pix Covert Art (albeit it’s only a 38KB jpeg).
I just wrote about this Evans album. I used MP3 Tag to check for cover art inside the file and I didn’t find it. Maybe MP3 Tag is not the right program for checking and editing flac files that contain image files.
Robert, it is usual for the artwork to be embedded in every track’s ID3 file. If not the artwork would disappear from the display on the player ( including Mosaic) every time you moved to a track without the embedded artwork.
Please note, however, that this is not unique to 24/192 tracks - all FLACs with artwork are like this irrespective of their audio resolution. So the issue here might be the large size of the audio data associated with 24/192 plus the size ( aggregated?) of the embedded artwork. Could this be a total data capacity issue that exceeds some ephemeral storage capacity in the processing by Mosaic, where if gapless works like other solutions, two tracks ( current and next) have to play at the same time at the track changeover point?
I converted the files from “flac” to “aif” and indeed Bill Evans and \ Pink Floyd’s album are playing correctly without interruptions. Unfortunately, AIF files are monstrously large and inconvenient to manipulate. I do not know if I am not breaking copyright law when converting, because AIF is already a copy. It seems to me that DCS should do something about it, because converting all live or played albums is a big challenge.
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.
