Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: standalone files VS. whole-album-in-one-file approach (Read 16684 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

standalone files VS. whole-album-in-one-file approach

Reply #25
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

standalone files VS. whole-album-in-one-file approach

Reply #26
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?

standalone files VS. whole-album-in-one-file approach

Reply #27
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.

standalone files VS. whole-album-in-one-file approach

Reply #28
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.

standalone files VS. whole-album-in-one-file approach

Reply #29
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.

standalone files VS. whole-album-in-one-file approach

Reply #30
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:
Quote
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?

standalone files VS. whole-album-in-one-file approach

Reply #31
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.

standalone files VS. whole-album-in-one-file approach

Reply #32
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.

standalone files VS. whole-album-in-one-file approach

Reply #33
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.
Infrasonic Quartet + Sennheiser HD650 + Microlab Solo 2 mk3. 

standalone files VS. whole-album-in-one-file approach

Reply #34
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.

standalone files VS. whole-album-in-one-file approach

Reply #35
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.
elevatorladylevitateme


standalone files VS. whole-album-in-one-file approach

Reply #37
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.
elevatorladylevitateme

standalone files VS. whole-album-in-one-file approach

Reply #38
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.

standalone files VS. whole-album-in-one-file approach

Reply #39
...and also the hidden track should be called "Track -1". 

 

standalone files VS. whole-album-in-one-file approach

Reply #40
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!