Hi everyone. I have not yet worked out my "this-is-how-I-will-organize-my-music" system and there is a big question that
everyone has sooner or later decided for himself/herself ... and that's where I would need your help, if you can:
Should I
split albums into standalone files
OR keep one single album file and use
links (cuesheets,etc.) ?
Can you name
pros and
cons of each of the 2 methods ?
(PS: I intend to use lossless file formats from now on, but will keep mp3s for which I don't have a lossless alternative, so I will still need to handle both formats in the future)
....................................................................................................
.........
I will update this section with pros/cons for both sides:
single album filePROS:- little gain of HDD space/reduction of fragmentation (little relevance to me, personally)
CONS:standalone filesPROS:CONS:
You could use cue sheet, or if you're using mp4/aac, simply specify chapters (which can be done using Yamb/MP4Box by importing a cuesheet).
But the vast majority of people use single files. It's still easy to play single files in album format (and do so gaplessly, if that's a reason you were thinking of going to single-album files). And you can also shuffle tracks, create playlists independent of album, etc.
If you're purely an album-guy, and ALWAYS listen to a single album at once, tracks-in-order, then you will save a SMALL amount of filespace by by encoding each album to a single file (because, at least in mp4/aac, you won't be wrapping the overhead of the container format around each song, but rather once for the whole album).
Depends on what player you use; whether it's something l33t like foobar or noobTunes.
Depends on what player you use; whether it's something l33t like foobar or noobTunes.
I am using winamp, but I am open-minded ... if there are important things you can doo with foobar but not wimap, I might consider switching.
If the purpose is exclusively archiving your CDs then it doesn't really matter which method you use.
But consider the various things you might want to do with your encoded audio now, and also consider what you might come to want in the future.
1: listening
2: transferring to portable audio player
3: transferring to home audio player
4: transcoding
5: streaming (home music server, web streaming etc)
6: burning CD
7: burning compilation CD
8: mixing/sampling
9: share/copy music with your family/friends
I'm sure there are lots more possibilities but those are the immediately obvious ones to me.
Another issue is that occasionally people change their preference in terms of software and even operating system. Right now Microsoft Windows dominates the desktop/home market almost completely. That wasn't always the case and isn't necessarily going to remain the case. In view of things like Drobo, Squeezebox, NAS in general, Android, Google OS on netbooks, Apple tablet/phone etc, we might soon be getting back to the situation where people commonly use a variety of different operating systems on different devices. So it pays to keep important data in formats that are easily portable and well supported universally, and to avoid formats, tools and methods that are tied to specific software or a specific OS.
With cue+files you can do anything that can be done with cue+image but the reverse isn't true without some extra work.
So I'd suggest very strongly to rip+encode to cue+files in preference to cue+image unless your aim is definitely only archiving and you are certain this will not change.
... single files. It's still easy to play single files in album format (and do so gaplessly, if that's a reason you were thinking of going to single-album files). And you can also shuffle tracks, create playlists independent of album, etc.
hm..., AFAIK all of this can be done with single-file albums, too.
wow Takla, that was *very* thourough!! thank you!
If the purpose is exclusively archiving your CDs then it doesn't really matter which method you use.
I'm not sure if I understand the premise. Yes, I want to archive my CDs (i.e. store them in lossless format on my HDD), but not "exclusively", as I collect music from other sources, too.
But consider the various things you might want to do with your encoded audio now, and also consider what you might come to want in the future.
I like your approach which always keeps an eye on the future. That's important.
1: listening
2: transferring to portable audio player
3: transferring to home audio player
4: transcoding
5: streaming (home music server, web streaming etc)
6: burning CD
7: burning compilation CD
8: mixing/sampling
9: share/copy music with your family/friends
1: YES
5+8: no
2+3+4+6+7+9: Yes, but I don't mind converting at all in these types of situation. I prefer a good solution for (1) (listening) and collecting my music and I'm ready to pay the price in terms of possible inconveniences for 2/3/4/6/7/9
With cue+files you can do anything that can be done with cue+image but the reverse isn't true without some extra work.
I'd be very thankful for
examples.
... unless your aim is definitely only archiving and you are certain this will not change.
Archiving as opposed to what?
PS: Can you explain in a few words what streaming/home music server is ?
In case you haven't searched, this discussion comes up quite regularly. It also comes up quite often as a side discussion in other related topics.
http://www.hydrogenaudio.org/forums/index....showtopic=68338 (http://www.hydrogenaudio.org/forums/index.php?showtopic=68338)
http://www.hydrogenaudio.org/forums/index....showtopic=62670 (http://www.hydrogenaudio.org/forums/index.php?showtopic=62670)
http://www.hydrogenaudio.org/forums/index....showtopic=71722 (http://www.hydrogenaudio.org/forums/index.php?showtopic=71722)
Moderators: This thread is definitely not about "CD Hardware/Software".
Can the one who moved this thread please move it back to General Audio (or a more appropriate section)? Thank you.
And why can't I edit my OP anymore (as opposed to all my other posts in this thread)? I wanted to update my OP as the thread goes along ...
PS: thank you for the links greynol!
While I can see where you're coming from in relation to players, I have a feeling that all other technical details are going to be about ripping, which is why I moved it.
You can't edit after an hour, sorry.
okay greynol, I don't think this is the right place, but with your experience here you certainly know better. let's see. Note however, that the links you posted are in "general audio", too and I want to talk about the same subject
You can't edit after an hour, sorry.
that's a pity, because there are types of discussion which require editing the OP. This is thread is an example. There are multiple other cases (e.g. guy posts free audio tool here and wants to post updates or new download link to the OP, etc.)
I use both types but according to my own preference.
I use separate files for all my albums.
This allows me to easily create my own compilations of music, picking and choosing individual tracks as I wish.
I use an additional single file for the whole album when it is released as a continuous mix.
An example is the "World of Goa Trance" releases, where each CD is a mix of 10 songs that merge into each other so it's one long ~60 minute session. As can be inferred, this is mainly for Trance/Euro type music. This also solves any gapless playback issues that may arise on a particular player setup. Gapless playback is of utmost importance with this type of music.
that's a pity, because there are types of discussion which require editing the OP. This is thread is an example. There are multiple other cases (e.g. guy posts free audio tool here and wants to post updates or new download link to the OP, etc.)
I think developers are exempt from this rule, but it may also depend on the forum, I'm not sure.
There's a topic about this which is pinned to the top of the Site Related Discussion (http://www.hydrogenaudio.org/forums/index.php?showforum=25) forum.
@greynol: thank you for the link and explanation.
I use separate files for all my albums.This allows me to easily create my own compilations of music, picking and choosing individual tracks as I wish.
cue sheet => songs added to player's media library => "easily create my own compilations of music, picking and choosing individual tracks as I wish"
......I'm not sure if I understand the premise. Yes, I want to archive my CDs (i.e. store them in lossless format on my HDD), but not "exclusively", as I collect music from other sources, too.
1: YES
5+8: no
2+3+4+6+7+9: Yes, but I don't mind converting at all in these types of situation. I prefer a good solution for (1) (listening) and collecting my music and I'm ready to pay the price in terms of possible inconveniences for 2/3/4/6/7/9....................................
By exclusively I meant if your ripping the CDs is purely for the purpose of backup, as opposed to wanting to do other stuff with the resulting files such as play them, edit them, distribute them, copy them and so on.
If you don't mind the extra work of splitting/converting then cue+image is as generally good as cue+files, but who likes extra work?
example of something that requires extra work if music is all cue+image: copying tracks to your portable player/manipulating metadata/copying a single track etc etc etc. Nothing is impossible but it means some extra work. Why should it be more complicated than copy+paste, or require a specific application? This can seem like a trivial point until you want to work with large batches of files when it can become time consuming, and of course building in an extra step (or series of steps) to accomplish a task also means building in more possibilities for mistakes to be made, both user error and software issues. A good motto is KISS - Keep It Simple Stupid! It's not always possible to keep everything absolutely simple, and complexity has very a strong appeal of its own for many people, but when dealing with files you created a long time ago (or files created by someone else) it's really a bonus if you don't need to remember/know
how they were created them and what super clever piece of software/process you now need to handle them (speaking from painful experience here).
home servers, streaming etc: a good place to start might be http://en.wikipedia.org/wiki/Media_server (http://en.wikipedia.org/wiki/Media_server) and http://en.wikipedia.org/wiki/Audio_streaming (http://en.wikipedia.org/wiki/Audio_streaming) and probably the hydrogenaudio wiki.
Standalone non-networked PCs are what we were used to, but now it's common to have (or want to have) quite sophisticated networked home entertainment. How about having all your music in one place and accessible and controllable by any device (PC, laptop, phone, PDA, tablet) on your home network? This is quite typical now, and easy enough to set up from scratch or you can buy an off the shelf solution....but if all your music is in a form the server doesn't know how to use (example: lossless image+embedded cue in 7z container) then your music archive is useless until you have laboriously converted it (perhaps to single track flacs or similar). But at least you'll have learned to write batch files or bash scripts by the time it's all straightened out
Cue+image imo is absolutely fine for archiving and ultimately usable whatever you like to do, while cue+tracks is absolutely fine for everything with no caveats.
@greynol: thank you for the link and explanation.
I use separate files for all my albums.This allows me to easily create my own compilations of music, picking and choosing individual tracks as I wish.
cue sheet => songs added to player's media library => "easily create my own compilations of music, picking and choosing individual tracks as I wish"
And if you use the music with something that doesn't support cue sheets, what then?
And if you use the music with something that doesn't support cue sheets, what then?
You get one big long file and have to manually search for the song (with the slider)
What this format is good for:
-Archiving, preserving all the gaps- and being overtly perfectionist
-Playback only using cue sheets and a player that supports them (anything else is too annoying when you just want to hear select songs)
-nothing else without first splitting it up anyway
if you can thing of nothing else useful to you (broader choice in software or anything else Takla mentioned) than by all means.
It seems that the consensus here and other posts I've read on this subject is that track files might be favored over the single file. I'm very new to this but would this single file also be referred to as an image?
I'd like to see a poll on what versions of the various formats are favored, something like this: http://www.hydrogenaudio.org/forums/index....showtopic=68338 (http://www.hydrogenaudio.org/forums/index.php?showtopic=68338) posted by greynol above.
An image need not just be a single file. Multiple files together can make up an image as well. When I use the term image in conjunction with a single file for all the audio I generally qualify it by saying single-file image.
Two other considerations:
- Multi-file "images", typically involve using non-compliant cue sheets, which can be unfortunate depending on the software you use (fb2k).
- Also, single-file images can allow you to play hidden track zero (by playing the file without the cue). Whereas with multiple-file "images" you either: [a] prepend hidden track zero (which forces you to listen to it each time you listen to track 1) separate it as it's own file (weird solution, IMO) or [c] discard the hidden track zero.
Multi-file "images", typically involve using non-compliant cue sheets, which can be unfortunate depending on the software you use (fb2k).
CUE sheets are not playlists and were never intended to be playlists. Besides, those who rip to individual tracks generally do not need CUE sheets unless they want to preserve index and other non-audio information, or if the CD has pre-emphasis.
weird solution, IMO
How is this weird? If someone wants their tracks as separate files, why shouldn't a hidden track also be contained in its own file? Makes perfect sense to me.
play hidden track zero (by playing the file without the cue).
What if they want to only play the hidden track or want to be able to skip to another track after listening to hidden track? This solution seems far more weird than the straight-forward approach of dedicating a hidden track to its own file.
An image need not just be a single file. Multiple files together can make up an image as well. When I use the term image in conjunction with a single file for all the audio I generally qualify it by saying single-file image.
I've very new to all this so I'm only testing EAC at this point for ripping to hard drive. So far I've only tried Action>Copy Selected Tracks, and Action>Copy Image And Create CUE Sheet. Both options show the tracks as separate in the folder. In that folder where the .flac files are stored they both look the same to me.
Also, single-file images can allow you to play hidden track zero (by playing the file without the cue). Whereas with multiple-file "images" you either: [a] prepend hidden track zero (which forces you to listen to it each time you listen to track 1) separate it as it's own file (weird solution, IMO) or [c] discard the hidden track zero.
Even though the HTOA track is the gap before track 1, it still makes sense to separate and write it as track 0.
Is there a more complete list of HTOA albums than at Wikipedia? : http://en.wikipedia.org/wiki/List_of_album...n_in_the_pregap (http://en.wikipedia.org/wiki/List_of_albums_with_tracks_hidden_in_the_pregap)
- little gain of HDD space/reduction of fragmentation (little relevance to me, personally)
It's the opposite for most modern filesystems (HFS+, NTFS, EXT*) BTW. Smaller files can be allocated much more efficiently regarding fragmentation than large files.
ok, you are right about the fragmentation (but you can always defragment your drive).
But "little gain of HDD space" is correct. See: Slack Space (http://www.pcmag.com/encyclopedia_term/0,2542,t=slack+space&i=56995,00.asp)
Well, the question is wether this is even worth mentioning. For example, NTFS' maximum cluster size is 4096 bytes. So on average you have about 2048 byte "slack space" per file. Let's make a conservative guess in your favor and say an average album has 15 tracks = 30720 byte "wasted" per album (and less fragmentation). Lets scale this to a terabyte music collection of 3000 lossless albums (333.33 MB each) := 45000 files := ~88 MB of unused cluster space. The price per GB for terabyte drives is about 0.05 €. So the difference, even for a large TB collection, is 0.0044 EUR of HD space. Not even a penny. Is that really worth mentioning?
PRO one-file-per-track:
Much easier to manage. All the playing and tagging applications ever need to understand is the audio codec and the tag format, beyond that it's business as usual for them.
But adding meta-data to one-file-per-CD rips is a pain in the ass. There's only one single application I know of that does it conveniently: fb2k. And foobar uses its own standard tag field names, so it's incomaptible to the next to-be-written application that could edit image rip metadata.
I know this isn't strictly on the topic of multiple files vs individual files, but it seems closely related to me.
Is there any disk space wasted / gained from tagging individual files vs using a cue sheet? It seems pretty obvious to me that you should only use one image file for the album art vs putting album art in the tag of each file, and similar gains from not labeling things like Album, Album Artist, etc for each track, but I'm not sure on that last part. Is there file padding that can be eliminated from files using tagging if you switched to a cue sheet? Of course, this depends on the file format and can be used / not used on both album-as-file images and track-as-file albums.
It seems pretty obvious to me that you should only use one image file for the album art vs putting album art in the tag of each file, and similar gains from not labeling things like Album, Album Artist, etc for each track, but I'm not sure on that last part.
Well, I usually do not put images into the tags. For the front cover art (which is the only image of the scans that is actually displayed in my player setup) I simply put a JPEG file into the album folder and name it "cover.jpg".
Is there file padding that can be eliminated from files using tagging if you switched to a cue sheet? Of course, this depends on the file format and can be used / not used on both album-as-file images and track-as-file albums.
1) I'm not sure if you can remove padding. But I know that you can add padding. It is usually the encoder that adds extra padding bytes during encoding if desired by the user.
2)You will loose some metadata when switching to cue sheet, unless your player utilizes the REM comment lines. For example if you want to add the barcode of the CD to the tag, you could write a line "REM BARCODE 07899723479" and pray that is it shown by the player. I won't bet on it. It's 101% non-standard.
3)You could add extra metadata which traditionally is not to be written to a cue sheet into extra tag fields. foobar2000 does it that way, but it would beat the purpose of saving a few bytes by merging redundant tag information from multiple files into one single file. Btw, it's also 101% non-standard.
2)You will loose some metadata when switching to cue sheet, unless your player utilizes the REM comment lines. For example if you want to add the barcode of the CD to the tag, you could write a line "REM BARCODE 07899723479" and pray that is it shown by the player. I won't bet on it. It's 101% non-standard.
Do any players do that? With the exception of foobar2000 supporting EAC-written values and its own Replay Gain fields, which brings me to:
3)You could add extra metadata which traditionally is not to be written to a cue sheet into extra tag fields. foobar2000 does it that way, but it would beat the purpose of saving a few bytes by merging redundant tag information from multiple files into one single file. Btw, it's also 101% non-standard.
Do you mean not in the cue sheet, but in cue_track_* fields?
Do any players do that? With the exception of foobar2000 supporting EAC-written values and its own Replay Gain fields, which brings me to:
I have no idea. As I said I don't know of any, and I assume that none exists. There are quite some players with embedded cue sheet support now, especially under Linux, I guess. Whether they only support the most often used non-standard metadata fields (REM DATE, REM GENRE, etc) which were made popular by EAC, or whether they generically treat the keyword after REM as a tag field name and the rest of the string as the tag field value... no idea. Would be easy to implement, tho.
Do you mean not in the cue sheet, but in cue_track_* fields?
Yes. It would also be easy to add this to other players. But I guess the problem is that the developers of those players do not feel the need to do so, because they probably rip each track to a seperate file.
Support for embedded cue sheets and one-file-per-CD rips has always been tough. And I'm pretty sure it will stay tough. That's reason enough for me to stay away from this path of ripping CDs.
Your suggestion of players supporting any custom field name in REM fields is one I've previously stated would be nice for foobar2000 (back when I used it regularly). But apparently this is non-standard and thus unacceptable! I can only conclude that some field names are less non-standard than others.
Separate files' best advantage is the fact that they're separate. If you want to upload/download such a file, write it onto another medium or portable device without writing the whole album, or if you want having a separate tag with lyrics or comments or track gain on certain tracks, it allows all that, and with much less trouble than the other method.
I missed this:
I know this isn't strictly on the topic of multiple files vs individual files, but it seems closely related to me.
Is there any disk space wasted / gained from tagging individual files vs using a cue sheet? It seems pretty obvious to me that you should only use one image file for the album art vs putting album art in the tag of each file, and similar gains from not labeling things like Album, Album Artist, etc for each track, but I'm not sure on that last part. Is there file padding that can be eliminated from files using tagging if you switched to a cue sheet? Of course, this depends on the file format and can be used / not used on both album-as-file images and track-as-file albums.
Negligible in almost all cases, I'd imagine, with the possible exception of cases in which the user chooses to embed (perhaps quite large) album art images in every one of their single files, rather than the more efficient solution (already noted by Fandango) of keeping one copy as a file in each album's folder. 'Redundant' text tags (e.g. album, artist, and the like--which actually aren't redundant, because all of them are needed if the file is to be used alone) will effectively make no difference given modern disk capacities.
This certainly shouldn't be thought of as anything near a deciding factor.
weird solution, IMO
How is this weird? If someone wants their tracks as separate files, why shouldn't a hidden track also be contained in its own file? Makes perfect sense to me.
It's weird because (despite my word-use in the above post) I generally think of track numbers as being ordinal, not nominal.
How does the use of numeral zero for the track before one not fit an ordinal system?
The "first track" is assigned the value of 0. The "second track" is 1. The "Third track" is number 2.
If you have a hidden track zero, what's the "album opener"?
Supposedly, one of the mental barriers that keeps society from being able to do greater amounts of arithmetic in our heads is our general concept that counting begins with one, not zero.--We think in groups of one-through-ten and not zero-through-nine.
For better or worse, I think the former way about CD tracks.
The hidden track is not the first track, the hidden track is the hidden track. The first track is the first track which is the "album opener". Perhaps your having to go through mental cartwheels to make sense out of this is akin to pressing the rewind button on your CD player.
Do you have a better solution for the majority of people on this forum who wish to have individual tracks saved as separate files? Remember, people who rip tracks as separate files can treat these images just as you're suggesting they do with single-file images: through the use of playlists.
...and also the hidden track should be called "Track -1".
Why? By that reasoning, what is track 0?
The latter makes sense to me. Typically INDEX 00s are appended to the previous INDEX 01. Track 1's INDEX 00 has no preceding INDEX 01, therefore it gets its own designation as the entirety of track 0.
Still, even this is overthinking!
Why? By that reasoning, what is track 0?
There is no track 0...
Still, even this is overthinking!
Of course, it's a joke.