Welcome Guest ( Log In | Register )

setting up a collection of monolithic wavpack files with tags?, how do i process comment tags for tracks inside monolithic wavpacks
post May 19 2010, 07:30
Post #1

Group: Members
Posts: 155
Joined: 18-May 10
From: Montana, USA
Member No.: 80732

First off, i'm using Gentoo Linux.

I have a collection of about 14k tracks ripped from CDs (that is if i can recover a hard drive gone bad, but that's another story) processed into individual flac files. I have lots of hours put into tagging especially comments (lead singer, disc type etc) and cover scans etc.

If i can recover this drive i want to re-do the collection. I'm interested in wavpack, as i've read many good things about it and i think it might meet my needs. Here's what i want to end up with:

1. All albums are a single file.
2. each file contains the album artist, year, genre. Individual tracks within the monolithic track contain the track number, track artist, performer and comment.
3. each file contains full covers (front, back, cd, liner notes 1, liner notes 2 ....etc)

What i'm not sure of is how to handle the "tags". I've been looking around the forums and it seems that the way to do this is with an embedded cue file. I've looked a few cue files over and i don't see where one would insert the comment tag but i'd swear i've read of it being done.

I'm going to be writing a bash script to convert/process all this automatically. I don't really need guidance with that but i'm wondering if this set up is feasible before i plunge in.

Will most media players read such a monolithic file and display the cover, and track information correctly during playback (i.e MPD, mplayer, etc)?

I am under the impression that wavpack will handle this better than flac.



Music lover and recovering high end audiophile
Go to the top of the page
+Quote Post
Start new topic
post May 21 2010, 10:54
Post #2

Group: Members
Posts: 1549
Joined: 13-August 03
Member No.: 8353

You could adopt foobar2000's way of storing per-track tags in a single album image:


So for example: CUE_TRACK01_TITLE

$tracknumber is always padded with a zero upto two digits, i.e. the first 9 tracks are padded.

But be aware that this is not a standard, foobar2000 is the only application that does it this way. It's needless to say that the most convenient way to edit the tags of such an album package is to use foobar2000 itself, it does everything transparently and you won't have to worry about the correct tag field names.

You are mentioning Unix programs, so I assume you don't use Windows for media playback. While you can use foobar2000 using Wine, you might not want to. Support for image rips was really bad a few years ago for non-Windows players, but it has improved a lot recently. But you might end up using a player not because you like its overall features, but because you have to because of its image rip support.

Well, good luck with your project. You will have to invest a lot of time and thought into it, and there are certain things that simply cannot be done. Also I'm pretty stuck with foobar2000 with these rips, which isn't a problem for me, but it's still not a good feeling to know that this might become an issue in a few years. So I gave up creating single image rips for these reasons, they are much harder to manage than per-track audio file rips. Though I'm not converting the existing image rips... not yet.

The main realization that tipped over my concerns with per-track files was that for playback on a PC (and actually on a CD player, too) the pre-gap information in the cue sheet, and hence the cue sheet itself is not needed. It has no impact on the listening experience. Also the pre-gap information isn't reliable in the first place, it depends on the ripper, drive model and CD what pre-gaps you get or if you get them at all. So I came to the conclusion that all this is heavily overrated, although it took me a while. Also I have absolutely no need to store everything in a single archive, but I realize that there are certain P2P-clients that are single-file-based rather than multi-file-based and that this might be the driving force for many people to embed everything into one piece.

As Bryan said, support for image rips isn't always complete in all players, still it's astounding to what lengths people go and bend the file format specs in order to get everything from a single directory into a single playable file or archive.

This post has been edited by Fandango: May 21 2010, 11:14
Go to the top of the page
+Quote Post

Posts in this topic

Reply to this topicStart new topic
0 Members:


RSS Lo-Fi Version Time is now: 28th December 2014 - 03:11