Multitrack files vs CUE
Posted by: AMA on 16 March 2011
Not sure everyone is aware of these options.
The problem is that one can hold the music as
1. *.wav (or .wv) + *.cue
2. A single multitrack *.flac
3. All tracks in separate *.flac files
Are those options equivalent?
I mean do we lose information when converting one form into another for some reasons?
What I found is:
1. Keeping *.wav+*.cue is equivalent to multitrack *.flac.
This means that conversion between *.wav + *.cue is absolutely reversible. Namely -- if you convert *.wav+*.cue into *.flac and then convert *.flac back to *.wav+*.cue you get absolutely the same *.wav and *.cue. Conversely, if you convert *.flac into *.wav+*cue and then back again you get absolutely the same *.flac.
Very good news.
2.
Converting *.wav + *.cue to multiple files and back is NOT precise.
When you get back to *.wav it matches the original *.wav but the *.cue is slightly different.
The only difference is the INDEX 00 (if any) is missed during conversion to multiple files. Namely: if original *.cue contained a track with INDEX00 then afetr conversion to a single *.flac track and the conversion all tracks back into a single *.wav + *.cue the new *.cue is missing INDEX 00.
The rest information including the INDEX 01 is the same.
Can anyone suggest if the loss of INDEX00 is important?
The problem is that one can hold the music as
1. *.wav (or .wv) + *.cue
2. A single multitrack *.flac
3. All tracks in separate *.flac files
Are those options equivalent?
I mean do we lose information when converting one form into another for some reasons?
What I found is:
1. Keeping *.wav+*.cue is equivalent to multitrack *.flac.
This means that conversion between *.wav + *.cue is absolutely reversible. Namely -- if you convert *.wav+*.cue into *.flac and then convert *.flac back to *.wav+*.cue you get absolutely the same *.wav and *.cue. Conversely, if you convert *.flac into *.wav+*cue and then back again you get absolutely the same *.flac.
Very good news.
2.
Converting *.wav + *.cue to multiple files and back is NOT precise.
When you get back to *.wav it matches the original *.wav but the *.cue is slightly different.
The only difference is the INDEX 00 (if any) is missed during conversion to multiple files. Namely: if original *.cue contained a track with INDEX00 then afetr conversion to a single *.flac track and the conversion all tracks back into a single *.wav + *.cue the new *.cue is missing INDEX 00.
The rest information including the INDEX 01 is the same.
Can anyone suggest if the loss of INDEX00 is important?
Posted on: 16 March 2011 by pcstockton
A "proper EAC rip" with correct gap detection with Cue file (with correct pre-gap info, and/or pre-emphasis flags) will recreate the CD perfectly with an EAC burn (using the resultant cue). Rip, burn, convert ad infinitum.
Posted on: 17 March 2011 by DavidDever
Why does it matter? NONE of these options are used within the professional CD assembly environment, and you're kidding yourself if you think that the process as you have described it is sample accurate in and out of a residue-encoding process such as FLAC.
Index 0 tracks (as well as other indices) are often used for continuous program material and must be preserved if sample accuracy is important (which it is, if fidelity to the original data is at all important)....
Index 0 tracks (as well as other indices) are often used for continuous program material and must be preserved if sample accuracy is important (which it is, if fidelity to the original data is at all important)....
Posted on: 17 March 2011 by AMA
Originally Posted by pcstockton:
A "proper EAC rip" with correct gap detection with Cue file (with correct pre-gap info, and/or pre-emphasis flags) will recreate the CD perfectly with an EAC burn (using the resultant cue). Rip, burn, convert ad infinitum.
Patrick, I know this -- but it does not help answering my question. I have two messages in my post and one question.
My first message was that converting *.wav + *.cue to a multitrack *.flac is completely reversible and keeping the library with single file *.flac is more comfortable than *.wav + *.cue.
The problem is that unlike Foobar many dedicated streamers don't work with multitrack *.flac, including Naim and Logitech. That's why I keep my tracks in separate *.flac.
My second message is that keeping tracks in separate files is NOT equivalent to original EAC rip and you are loosing information on INDEX 00 (if it was present).
In my experience all INDEX 00 are about 1 second length and not musically informative.
At the same time my Logitech Transporter plays separate *.flac tracks ABSOLUTELY gapless.
So I guess INDEX 00 does not affect the gapless playback.
So now the question comes -- what the INDEX 00 is doing?
Posted on: 17 March 2011 by AMA
Originally Posted by DavidDever:
Why does it matter? NONE of these options are used within the professional CD assembly environment, and you're kidding yourself if you think that the process as you have described it is sample accurate in and out of a residue-encoding process such as FLAC.
Index 0 tracks (as well as other indices) are often used for continuous program material and must be preserved if sample accuracy is important (which it is, if fidelity to the original data is at all important)....
Index 0 tracks (as well as other indices) are often used for continuous program material and must be preserved if sample accuracy is important (which it is, if fidelity to the original data is at all important)....
David,
So what is the options which is "used within professional CD assembly"?
And what is the option you may suggest to your Clients (non-professional home users) of what is the best way to keep tracks on NAS?
Posted on: 17 March 2011 by Aleg
Originally Posted by AMA:
Originally Posted by pcstockton:
A "proper EAC rip" with correct gap detection with Cue file (with correct pre-gap info, and/or pre-emphasis flags) will recreate the CD perfectly with an EAC burn (using the resultant cue). Rip, burn, convert ad infinitum.
Patrick, I know this -- but it does not help answering my question.I have two messages in my post and one question.
My first message was that converting *.wav + *.cue to a multitrack *.flac is completely reversible and keeping the library with single file *.flac is more comfortable than *.wav + *.cue.
The problem is that unlike Foobar many dedicated streamers don't work with multitrack *.flac, including Naim and Logitech. That's why I keep my tracks in separate *.flac.
My second message is that keeping tracks in separate files is NOT equivalent to original EAC rip and you are loosing information on INDEX 00 (if it was present).
In my experience all INDEX 00 are about 1 second length and not musically informative.
At the same time my Logitech Transporter plays separate *.flac tracks ABSOLUTELY gapless.
So I guess INDEX 00 does not affect the gapless playback.
So now the question comes -- what the INDEX 00 is doing?
AMA
I support Patrick in this.
When:
- you do a proper rip with all pregap information stored into the cue, and
- you do a cue-split (that is split a multitrack to multiple single tracks using the cue) and
- keep the newly created cue-file which then contains all the information required but now based on the single track files
then you can recreate the original multitrack files with no loss of information.
I have done it, it is exactly the same as the original multitrack rip, but is a hassle.
Proper tools to do all this: EAC or dBPowerAmp for the ripping + CueTools (for the splitting and rebuilding)
INDEX 00 is the pre-gap information. It is where the track starts with the pause
INDEX 01 is the track start with the actual first notes of the music
Sometimes track 1 also contains information before the actual music stored in the pre-gap of track 1, AKA as "hidden track", this can be extracted by some rippers/splitters as to a file with HTOA as filename.
Information about CUE sheets
-
aleg
Posted on: 17 March 2011 by AMA
Aleg,
Again and again -- I fully agree with Patrick and you. I do the same as both of you suggest.
I keep all tracks in separate *.flacs and also I keep the original *.cue which came with *.wav after EAC ripping. If I need to restore a CD I just build a *.wav from separate tracks and couple it with original *.cue -- and I'm done with EXACT copy of original CD.
I still have a question which is not explicitly answered -- do I need the original *.cue?
I know if I delete it then the only information I lose is the INDEX00.
Is that audible?
Again and again -- I fully agree with Patrick and you. I do the same as both of you suggest.
I keep all tracks in separate *.flacs and also I keep the original *.cue which came with *.wav after EAC ripping. If I need to restore a CD I just build a *.wav from separate tracks and couple it with original *.cue -- and I'm done with EXACT copy of original CD.
I still have a question which is not explicitly answered -- do I need the original *.cue?
I know if I delete it then the only information I lose is the INDEX00.
Is that audible?
Posted on: 17 March 2011 by Aleg
If you rip with "add gap to previous track" than you keep all original spacing between tracks. Loosing the INDEX 00 is not audible because it only has to do with marking the beginning (InDEX 00) or the end (INDEX 01) of the silence between tracks.
-
Aleg
-
Aleg
Posted on: 17 March 2011 by AMA
Aleg, thanks! I thought so. I have a lot of gapless music which is currently split into separate tracks but my Transporter plays them gapless. So I start thinking why do I keep the original *.cue?
I can always build the cue (sans INDEX00 if any).
Can you share your experience on how do you keep your music tracks on the NAS?
I can always build the cue (sans INDEX00 if any).
Can you share your experience on how do you keep your music tracks on the NAS?
Posted on: 17 March 2011 by Aleg
Hi AMA
I keep my music on my NAS in separate tracks (ripped with Gap added to Previous track). I have to do this because the players I use don't support multi-track files+CUE-sheet.
Besides this, for archival purposes, I keep a multi-track file+CUE-sheet.
In the beginning I have experimented with keeping the music in separate tracks (for my players) + CUE-sheet for rebuilding the multitrack rip as for archival purposes. This CUE includes all original indexes and is based on the single track files, this CUE was created by CUE-Tools when splitting the multi-track to single tracks. This way I could save on disk space and still be able to rebuild an image of the original CD.
Due to dropping prices of hard disks and the hassle of having to rebuild an image if I want one, I just went for both single tracks for playback and image+CUE for archiving.
My ideal would be that Naim networked players would be capable of reading full-CD images + CUE-sheets and present them in the software as single tracks.
-
Aleg
I keep my music on my NAS in separate tracks (ripped with Gap added to Previous track). I have to do this because the players I use don't support multi-track files+CUE-sheet.
Besides this, for archival purposes, I keep a multi-track file+CUE-sheet.
In the beginning I have experimented with keeping the music in separate tracks (for my players) + CUE-sheet for rebuilding the multitrack rip as for archival purposes. This CUE includes all original indexes and is based on the single track files, this CUE was created by CUE-Tools when splitting the multi-track to single tracks. This way I could save on disk space and still be able to rebuild an image of the original CD.
Due to dropping prices of hard disks and the hassle of having to rebuild an image if I want one, I just went for both single tracks for playback and image+CUE for archiving.
My ideal would be that Naim networked players would be capable of reading full-CD images + CUE-sheets and present them in the software as single tracks.
-
Aleg
Posted on: 18 March 2011 by AMA
Originally Posted by Aleg:
My ideal would be that Naim networked players would be capable of reading full-CD images + CUE-sheets and present them in the software as single tracks.
Aleg, What exactly do you mean by "full-CD image": a single-track *.wav image, a single track *.flac image or standard CD-image file?
Also I found out that multi-track *.flac is bit-equivalent to *.wav + *.cue so you can always burn the bit-perfect copy of original CD.
Why not to stick with this and just apply for Naim to support multitrack *.flacs?
I know for sure it's not a big deal in terms of programming efforts.
There are free implementations of multi-track FLAC interface in open C++ code.
Posted on: 18 March 2011 by Hook
AMA & Aleg -
Dumb question: why be concerned about being able to re-create the CD image?
For me (ripping to multiple flac files, no cue sheets) is a one way street. Once the music is on my hard drive, I can not think of any use for the CD image.
The only reason I retain the CD at all is as proof-of-purchase. In fact, that reminds me....am planning a tedious space reclamation project by repackaging my 1600+ CD's into soft sleeves. Would love to get rid of all the jewel boxes...would be nice to find a soft sleeve that can also hold the booklet and back tray card as well. Sorry, never mind....OT.
Thanks.
Hook
Dumb question: why be concerned about being able to re-create the CD image?
For me (ripping to multiple flac files, no cue sheets) is a one way street. Once the music is on my hard drive, I can not think of any use for the CD image.
The only reason I retain the CD at all is as proof-of-purchase. In fact, that reminds me....am planning a tedious space reclamation project by repackaging my 1600+ CD's into soft sleeves. Would love to get rid of all the jewel boxes...would be nice to find a soft sleeve that can also hold the booklet and back tray card as well. Sorry, never mind....OT.
Thanks.
Hook
Posted on: 18 March 2011 by AMA
Hook,
You are absolutely right. There is absolutely no need in burning the CD back again.
Why doing this if I already have them all collecting the dust in the bookcase ?
The ability of getting a bit-perfect copy of original CD is a figure of speech which means that you are holding the data which is equivalent to the true and authentic copy of original CD. That's it.
If you look back at the begging of my thread you will see that I'm putting the very same question. I'm currently keeping my tracks in separate *.flac files and also I'm keeping an archive copy of *.cue.
My experiments show that the separate *.flac files generate almost the same *.cue.
I was suspecting that the loss of INDEX00 is not important in musical terms. And Aleg confirms this. This means we can delete *.cue from our folders (though I'm not going to do it for the sheer superstitious reasons -- similar to those which keep us from ditching the old cassette decks or old vinyls or a beloved pillow).
When deleting the *.cue one has to understand that he will not get a bit-perfect copy of original CD in case he wants to. But the discrepancy with original CD does not translate into musical information.
Neither it affects a gapless playback.
You are absolutely right. There is absolutely no need in burning the CD back again.
Why doing this if I already have them all collecting the dust in the bookcase ?
The ability of getting a bit-perfect copy of original CD is a figure of speech which means that you are holding the data which is equivalent to the true and authentic copy of original CD. That's it.
If you look back at the begging of my thread you will see that I'm putting the very same question. I'm currently keeping my tracks in separate *.flac files and also I'm keeping an archive copy of *.cue.
My experiments show that the separate *.flac files generate almost the same *.cue.
I was suspecting that the loss of INDEX00 is not important in musical terms. And Aleg confirms this. This means we can delete *.cue from our folders (though I'm not going to do it for the sheer superstitious reasons -- similar to those which keep us from ditching the old cassette decks or old vinyls or a beloved pillow).
When deleting the *.cue one has to understand that he will not get a bit-perfect copy of original CD in case he wants to. But the discrepancy with original CD does not translate into musical information.
Neither it affects a gapless playback.
Posted on: 18 March 2011 by pcstockton
Originally Posted by Hook:
would be nice to find a soft sleeve that can also hold the booklet and back tray card as well.
These work pretty well. I have 4 of the huge ones. Case Logic.Posted on: 18 March 2011 by AMA
Looks like a CD cemetery ....
Posted on: 18 March 2011 by likesmusic
hook - checkout arrowfile
Posted on: 19 March 2011 by Hook
Patrick & Likesmusic -
Thanks for the pointers -- much appreciated!
Both products are very nice, but seem oriented towards people who have CD players and need to regularly access their collection. I just want to box mine up (while keeping the box weight down), and either toss the jewel cases, or maybe just move those out to the garage.
I just found these "jewel sleeves", and other than the cost (40 cents per!), they are pretty much what I am looking for. Here's how they work...
http://www.jewelsleeve.com/nonHTML/jewelsleeve.mov
Hook
Thanks for the pointers -- much appreciated!
Both products are very nice, but seem oriented towards people who have CD players and need to regularly access their collection. I just want to box mine up (while keeping the box weight down), and either toss the jewel cases, or maybe just move those out to the garage.
I just found these "jewel sleeves", and other than the cost (40 cents per!), they are pretty much what I am looking for. Here's how they work...
http://www.jewelsleeve.com/nonHTML/jewelsleeve.mov
Hook
Posted on: 19 March 2011 by BigH47
Also Google "jloft sleeves"
Posted on: 19 March 2011 by AMA
Originally Posted by BigH47:
Also Googlre "jloft sleeves"
That looks interesting - twofold design, just like a plastic case. It supports international shipping and goes for 0.22 $/sleeve only.
Posted on: 19 March 2011 by Hook
Originally Posted by BigH47:
Also Google "jloft sleeves"
Perfect! Order placed. Thank you BigH47!
Hook
Posted on: 19 March 2011 by Guido Fawkes
I use a similar design from Halifax based Covers33, they were 25p each.
I suspect both work extremely well.
All the best, Guy
I suspect both work extremely well.
All the best, Guy