My older version of XLD was simpler, it’s on another Mac.
The current version has an option to include ReplayGain tags set by default as well as embedding Cue Sheets.
My gut feeling is that even if Naim streamers ignore ReplayGain tags I’m not sure I want them in the file in the first place. Presumably one could run the tracks through a converter and apply them at a future date if needed anyway? Any thoughts?
Anyone know if the embedding Cue Sheets option actually embeds them in a file, as a Cue sheet is saved in the directory anyway. Guess I could run two rips with and without and compare file sizes. Again if it’s in the file it may be overhead I don’t need.
Suspect some of the options are there by virtue of the FLAC encoder itself not necessarily XLD.
As I embark on ripping less than a dozen CDs (yes some from Poundland), I’m really getting a sense I can’t be bothered. As much as I’ve always wanted physical media/purchased downloads, I currently probably spend less than 5% of my time listening to music streamed locally from the NAS, and most of it playing Qobuz streams via Roon or playing vinyl. This rather surprises me.
Hi, with replay gain, I would leave it there. Most renderers I imagine would ignore it, and I suspect most that would support it will have an option of enabling it or not… it’s potentially useful info to have associated with the media rip.
As far as cue sheets, these are not stored with meta data, at least I can’t see how in a meaningful way.
Natively redbook audio CDs provide one single PCM audio ‘fike’. This is split up into specific start and stop times within that file, and in the CD this information is held in the CD Table of Contents header.
A Cue sheet simply extracts this timing info into a separate file, and sometimes the cue sheet can contain sub channel information such as CD text. This is data interleaved with the sample data within the single Redbook file.
Cue sheets tend to be only useful if you ripped your CD as a single file… and you manually want to make your own track files for whatever reason.
Documentation for XLD is scanty at best, but can’t really complain when it’s free!
I’d assume the ReplayGain data would not be that large anyway, found some older threads and some discussing other equipment where it can be used by the DLNA server or turned on/off as you suggest on the streamer/renderer.
Never used cue sheets in the past and frankly unlikely to do so in the future - it may be the ‘embed’ option simply means in the destination folder not the file itself.
Years ago I’d have been merrily tweaking all manner of advanced parameters in audio/video encoders, these days I just want simplicity but that may reflect the fact that these things are generally far more mature with good default options.
Hi, on reading my reference notes, I can see that WAV file does support labelled sub chunks, which allows you to label a specific set of samples with a name within the WAV file… this is part of the List INFO meta data construct of the WAV file. This is the official standardised version of WAV meta data that tends to be used more commercially and in music/media production rather than in consumer software…
So I could see that the cue sheet could be split up and the relevant part embedded into each ripped file and stored as a labelled sub chunk in that file… perhaps that is what is meant by embedded…if so I still can’t really see the point… normally this feature would be used for naming regions of a WAV file for authoring and editing purposes.
Presumably virtually any data could be inserted as metadata, but only software designed to identify it would have any use for it. The option was in this FLAC dialogue box:
I’ve tended to avoid compressed FLACs when ripping assuming there would be some processing overhead when decompressing the file (which may not matter as much if Roon/Asset/Minim etc are sending to RAAT or converting to WAV) on a Naim streamer. That said network transfers might benefit and I’d not be surprised if the FLACs from Qobuz etc are compressed to aid downloading speed and bandwidth needed by their servers.
Yes, the RIF file structure supports this… you can create your own custom chunk or sub chunk IDs, as long as no one has registered or using that ID, and simply encode into the file as appropriate. Compliant RIF file readers are expected to skip chunks they don’t recognise.
As far as processing overhead on decompressing FLAC files, yes there is, interestingly the overhead is constant irrespective of the degree of FLAC compression.
Because of this many transcode the FLAC to WAVE at the media server side, or if they do decode in the renderer they use a separate DAC, such that any noise caused by the extra processing is decoupled from the circuitry that would be sensitive to such effects.
Storing WAVE files uncompressed is rather inefficient and wasteful… especially when you have tens of thousands of tracks or more.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.