Appreciate all your reverts.
The primary purpose of my post was whether ROON handles / likely to handle (in the near future) .cue & .iso files. I believe that query has been definitively answered, and I appreciate that.
I will refrain from the other topics. It is not my intention to kick up any firestorm.
I politely I agree to disagree.
Cheers
This post by a member of the Roon team may help: Splitting tracks (FLAC + CUE files) [Answered - Use Cue Splitter]
and you may wish to consider this:
[quote]$ ls -la
total 41088
drwxr-xr-x 2 x users 4096 Apr 2 08:28 .
drwxrwxr-x 8 x users 4096 Apr 2 08:25 âŠ
-rw-rw-rw- 1 x users 42065564 Apr 2 08:21 test.wav
$ md5sum test.wav
6037ed10ab8cb478b5aa49f6712649a5 test.wav
$ flac -8 --delete-input-file *.wav
flac 1.3.2
Copyright © 2000-2009 Josh Coalson, 2011-2016 Xiph.Org Foundation
flac comes with ABSOLUTELY NO WARRANTY. This is free software, and you are
welcome to redistribute it under certain conditions. Type `flacâ for details.
test.wav: wrote 28141103 bytes, ratio=0.669
$ ls -la
total 27492
drwxr-xr-x 2 x users 4096 Apr 2 08:29 .
drwxrwxr-x 8 x users 4096 Apr 2 08:25 âŠ
-rw-rw-rw- 1 x users 28141103 Apr 2 08:21 test.flac
$ flac -d *.flac
flac 1.3.2
Copyright © 2000-2009 Josh Coalson, 2011-2016 Xiph.Org Foundation
flac comes with ABSOLUTELY NO WARRANTY. This is free software, and you are
welcome to redistribute it under certain conditions. Type `flacâ for details.
test.flac: done
$ ls -la
total 68572
drwxr-xr-x 2 x users 4096 Apr 2 08:29 .
drwxrwxr-x 8 x users 4096 Apr 2 08:25 âŠ
-rw-rw-rw- 1 x users 28141103 Apr 2 08:21 test.flac
-rw-rw-rw- 1 x users 42065564 Apr 2 08:21 test.wav
$ md5sum test.wav
6037ed10ab8cb478b5aa49f6712649a5 test.wav
$[/quote]
and then finally this:
[quote]$ ls -la
total 41092
drwxr-xr-x 2 x users 4096 Apr 2 08:34 .
drwxrwxr-x 8 x users 4096 Apr 2 08:25 âŠ
-rw-rw-rw- 1 x users 42065564 Apr 2 08:21 test.wav
$ flac -8 --delete-input-file *.wav
flac 1.3.2
Copyright © 2000-2009 Josh Coalson, 2011-2016 Xiph.Org Foundation
flac comes with ABSOLUTELY NO WARRANTY. This is free software, and you are
welcome to redistribute it under certain conditions. Type `flacâ for details.
test.wav: wrote 28141103 bytes, ratio=0.669
$ ls -la
total 27492
drwxr-xr-x 2 x users 4096 Apr 2 08:34 .
drwxrwxr-x 8 x users 4096 Apr 2 08:25 âŠ
-rw-rw-rw- 1 x users 28141103 Apr 2 08:21 test.flac
$ metaflac --show-md5sum test.flac
69abf9a1e2accdbee036f086c0021191
$ flac -d *.flac
flac 1.3.2
Copyright © 2000-2009 Josh Coalson, 2011-2016 Xiph.Org Foundation
flac comes with ABSOLUTELY NO WARRANTY. This is free software, and you are
welcome to redistribute it under certain conditions. Type `flacâ for details.
test.flac: done
$ rm *.flac
$ ls -la
total 41088
drwxr-xr-x 2 x users 4096 Apr 2 08:36 .
drwxrwxr-x 8 x users 4096 Apr 2 08:25 âŠ
-rw-rw-rw- 1 x users 42065564 Apr 2 08:21 test.wav
$ flac -1 --delete-input-file *.wav
flac 1.3.2
Copyright © 2000-2009 Josh Coalson, 2011-2016 Xiph.Org Foundation
flac comes with ABSOLUTELY NO WARRANTY. This is free software, and you are
welcome to redistribute it under certain conditions. Type `flacâ for details.
test.wav: wrote 29934159 bytes, ratio=0.712
$ ls -la
total 29244
drwxr-xr-x 2 x users 4096 Apr 2 08:36 .
drwxrwxr-x 8 x users 4096 Apr 2 08:25 âŠ
-rw-rw-rw- 1 x users 29934159 Apr 2 08:21 test.flac
$ metaflac --show-md5sum test.flac
69abf9a1e2accdbee036f086c0021191
$[/quote]
You are correct here, however, the large file + CUE was only required in the past when players could not play a sample accurate gapless stream. This is no longer a real problem with modern playback engines designed to handle this properly.
FLAC file lengths can be CD sector accurate (no padding), and Roon can play sample accurate gaplessly.
In Roon, whether you stream TIDAL or play FLACs (or any other file format that does not pad), the playback is gapless as long as the format of the audio is the same. Itâs as good as a CUE file. In some ways, even better, since you can gaplessly play between non-contiguous tracks (like Nonagon Infinity, which is gapless from last track to first track.)
To directly answer your question:
We feel that CUE files are an obsolete piece of technology, and that there are better more flexible ways to store your content with no loss in quality, assuming the software handles the playback properly. We may add support for CUE files in the future, as a way to support Roon members that have data in this legacy format, but if we do, it would result in reduced functionality as the format is not as flexible as our feature set requires.
Danny, Thank you for an informative & constructive post. It has introduced me to concepts I have not been familiar with, and got me thinking of possible migration out of .cue files.
While I have googled a bit based on pointers in your post, could you please provide some info / links for additional reading on the following:
How do I rip a CD so that ROON can playback with the same gaps as on the original CD ? (I presume that is what you refer to as âSample Accurate Gapless Streamâ ?
I read that .wav files can be with our without padding. Are the .wav files created when ripping a CD necessarily with our without padding, or is it un-predictable?
In essence, I want to know is I can rip in .wav and still have ROON playback with the same gaps as on the original CD ? or is this possible only with uncompressed FLAC ?
Your thoughts / pointers on the above, would be most helpful.
There is no difference between compressed and uncompressed FLAC. It all decodes to exactly the same audio stream as I demonstrated above.
The math and science may be âexactâ as you have âdemonstratedâ
For something as subjective a pursuit as audiophile playback, individual impressions may varyâŠ
I use dBpoweramp on Windows (An OSX version is also available).
Ripping to FLAC level 8 compression.
Using this folder/filename format:
Artist / Album / 01-01 Track Name.flac
Works fine, if you prefer use could use ALAC rather than FLAC.
I donât rip to wav, FLAC and ALAC are more robust (check summed) and also metadata support tagging.
There is zero difference in AQ of the formats, they are all lossless formats and yield the same audio data.
However, Roon supports wav, if you insist on using it.
Thank you, Carl.
Will try tonight.
Seeing as you already have cuesheets and FLAC files this is probably what youâre after and addresses your concerns re gaps.
If you hear a difference, either something was done wrong in the extraction or you are generating some external influence that impacts your system.
Iâm not suggesting it sounds the same to you, Iâm just saying that with Roon, there is absolutely no difference in the bytes going to the DAC if you had a CUE vs a bunch of FLACs.
Let me explain that explicitly. If Roon was to play FLAC with CUE files, it would just treat that CUE designated part of the FLAC as a new track. It would get no special treatment by the playback engine. It would be literally the same mechanism at playback time. The contiguous tracks being contiguous in the same file would have no impact since they would be split into tracks in memory well (many seconds) before the playback happened. Then they would be played back sample-accurately and gaplessly. This is why we can also do TIDAL tracks gaplessly.
I encourage you to find the cause of the difference you may or may not be hearing. I know your canât A/B test with Roon since we donât support CUE files. What other player do you hear differences with and what is your setup? Maybe we can help find the cause.
Also, instead of re-ripping your CD, you are less likely to introduce new errors by splitting the existing FLAC+CUE like @evand suggested. You can then decode those to WAV if you wish, but that step is just wasteful since we do it already inside of Roon (the FLAC file is decoded to PCM, just like the WAV file holds).
Thanks evand.
I use EAC (Exact Audio Copy) to rip (always into wav, if I may add 
) and Medieval Cue Splitter, if I need to chop into individual tracks.
Both are freeware, and have served me well for years.
EAC is great.
As far as I know MCS is is not considered a good solution for purists and precisely for reasons of the kind that are of concern to you:
From their homepage:
Known bug: MPC engine can cause a bit of jitter at the beginning/end of tracks.
Limitations: MD5 checksum is not calculated for generated FLAC files.
Theyâre clearly not using the reference FLAC implementation.
danny,
Let me explain: If I ripped into individual tracks and then burn a CDR with those fipped tracks, in exactly the same order as the original CD, no online data base will ever recognise the disk.
However if I rip to .cue + a single wav / flac file, and re burn on to a CDR, the CDR is instantly recognised by online CD databases.
All bits are often Not equal for many audiophiles⊠else why would I hear differences between an accuriped file re-burnt on a CDR and the original pressed CD ?
I guess many will not agree with my contention that the CDR sounds worse than the original disk⊠but lets agree to disagree on that 
Yes, evand.
The key here is the (FLAC) implementation. Not every one is as careful as ROON and that probably gives FLAC a bad name.
Staying with wav is an easier solution, since wav to the cd-da file is only a small step of discarding a headerâŠ
I think this is the route of the difference you hear but that is not a proof that WAV and flac are different.
I donât have time to find it but search for either Danny or Brianâs posts on the ideal setup for audio playback that removes all the noise issues you perceive when listening to files played back on a PC.
Essentially, playback on a PC isnât considered by many to be an audiophile way to listen to digital music.
Such âdeep truthsâ can be hard to let go of. But, consider that there are many, many folks around here that would describe themselves similarly as audiophiles. Said people have no issues running flac to get proper playback with Roon.
Burning CDâs? Whatâs that ?
I see then at Audio Shows all the time 
ohâŠthose vintage shows. I heard about them
sounds good⊠keep them then Given how bad quality CDRs are, I personally would never do this, but if thatâs a use case for you, go for it.
This is the EMI/RFI idea â It can be a legit problem, but the answer is to do proper isolation of your DAC. Right now, a random operating system process could come in and raise your CPU much more than a FLAC decode. Your goal is sane, but your methodology has gaping holes in it. By using physical, electrical, and RF isolation, you can avoid ALL these problems. This is why Roon Ready and RoonBridge exist.
This is because the âbits are bitsâ argument is being misunderstood by both camps. The computer guys know bits are bits, and the electrical engineers know that bits are not bits. Both are right, but you must not confuse the two ideas. If you try to solve the problem of âbits are not bitsâ, do it in the domain where that is actually true, and not in the domain where âbits are bitsâ.
In this specific case, you are introducing so many variables by introducing burning to a CDR, you are not doing an apples vs apples comparison. Here is how you should do that CDR test:
rip your CD multiple times, confirming that your CD is being ripped identically every time, and that your CD ripper is not broken by giving you different bytes out. If it is different, throw away your CD ripper. All tests from this point are useless until you have a working CD ripper.
burn multiple CDRs with the bytes from step 1
re-rip those CDRs and confirm that their data is identical to the data from step 1. This will double prove that your ripping process is good, and it will confirm that your CDR burning process is good too. If they dont match, your problem lies in the CDR. Either the physical media is bad, the ripping process that worked for CDs doesnt work for CDRs, or your burning process is bad. In all cases, your CDR ripper/burner/media is the culprit, and not the bits.
If all that passes, play 2 CDRs and confirm that they are sonically identical. If they are not, then your CD player can not play CDRs properly. This could be something to do with the error correction mechanism or jitter introduced by the CD player. If this is broken, the problem is the CD player, and not the bits (because youve already proven they are identical in step 3. The only difference in this test is the CDR media, not the bits.
if all is good, conduct the last test: Play the original CD and compare it to the CDRs being played in step 4. if it sounds different (which you think it does), then because of step 3, youve already verified there is no difference in the data on the CD vs CDR, the only difference is the media itself, and therefore your CD player can not play the CDR the same way as it can play your CD. Once again, error correction and jitter are the 2 obvious culprits here.
Yes, it is a lot of work, but if you are actually interested in the answer and not just dogma (repeated by people who probably did no such tests), this is the only way to find the problem in the system.
Only the ignorant will disagree. Do the tests, let people poke holes in the methodology.
You are right, many pieces of software do not take care to be so accurate in their playback, especially between tracks. Thatâs another reason to stop using those pieces of software. If they canât fix the basics, who knows what other mistakes they are making.
Storage is cheap, if this makes you less anxious, go for it!
@Dinyar_Contractor â did you get a chance to try out Carlâs or evandâs suggestions? Im guessing you havent had time for my big test yet
Danny,
Your post is very logically presented, and faultless. Appreciate.
No I have not gone thru the intensive trial and errors⊠They will, I believe identify the less than ideal hardware I am using.
My aim is infact not to perfect that hardware chain⊠its too distracting from listening to music, but to establish for my set up, what sounds better, and then, as far as possible stay with the option (that I have installed) that sounds the best.
I also have not heard a CDR (created by someone else) that sounds as good as the original, so I guess, similar (to mineA) hardware imperfections are almost a rule rather than an exception.