Skip to main content
Topic: WavPack embedding reference (Read 8663 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

WavPack embedding reference

hello (bryant),
i've been a long time wavpack user. i really like the idea of having everything in <one> file. at the moment i am encoding my cds into one file + emdedded cuesheet.
as it appears in the manual the reserved or better standardized field for embedding cuesheets is the tag "cuesheet" (and not cue, cue-sheet, or anything else)

i think it would really be helpful to standardize some other fields for embedded logs and coverart. this could also help to get more player support for embedded albumart and logs.

the -cc option for example is a really useful feature but i still have to manually extract the log files when decoding. if the tag for embedding log files would be standardized you could make a switch that extracts everything that is embedded. at the moment this is simply not possible as nobody knows how to embed log files for exmaple. that tag might be "log" or "logfile" or "extraction log" ...

just a suggestion...
thank you for your hard work, bryant.

WavPack embedding reference

Reply #1
you could make a switch that extracts everything that is embedded

+1

I guess it's not that hard to automate the distinction between binary/multi-line text and a simple tag without newline. The basename of the files could be based on the tag field's name and the wv file, for example.

WavPack embedding reference

Reply #2
Well, there already is an official tag for cover art (front and back), and I certainly have no problem with standardizing on a tag name for logs. My vote would be for logfile with an extension of .log; unless someone has strong objections I’ll add it to the official list.

I would have to think about the best way to automate extraction, especially with multiple files being unpacked at the same time, but I’m sure I could come up with something reasonable. Obviously the logfile could work just like cuesheet works now, but binary files could get weird.

Thanks for the suggestions! 

WavPack embedding reference

Reply #3
thank you for answer, bryant.

my vote is the tag "log" with extension .log (as i've done it this way with over 1000+ albums  hehe)

WavPack embedding reference

Reply #4
My vote would be for logfile with an extension of .log; unless someone has strong objections I’ll add it to the official list.
*raises hand*

I'd prefer "eaclog", because there can be more than just an EAC log for a CD image, although it is probably the most common one. Think of tools like auCDtect or ARCue/CUETools.

WavPack embedding reference

Reply #5
I'd prefer "eaclog", because there can be more than just an EAC log for a CD image, although it is probably the most common one. Think of tools like auCDtect or ARCue/CUETools.

And then some of us use RubyRipper... I don't think the name should be tied to a Windowscentric program...
"ONLY THOSE WHO ATTEMPT THE IMPOSSIBLE WILL ACHIEVE THE ABSURD"
        - Oceania Association of Autonomous Astronauts

WavPack embedding reference

Reply #6
+1 for for logfile with an extension of .log, thanks.
WavPack 5.1.0 -b384hx6cmv / qaac 2.64 -V 100

WavPack embedding reference

Reply #7
I'd prefer "eaclog", because there can be more than just an EAC log for a CD image, although it is probably the most common one. Think of tools like auCDtect or ARCue/CUETools.

And then some of us use RubyRipper... I don't think the name should be tied to a Windowscentric program...

Even though I only use Windows and EAC, I agree with both these statements.

WavPack embedding reference

Reply #8
Okay, I did a quick check on some WavPack files I have downloaded from BitTorrent (for this exact purpose) and found that "log" seems to be the most common field name, so I'll go with that.

I still have to think of a good way of handling extraction, but for wvunpack maybe something like --extract-log would work. Is an option for extract to stdout needed, like with the cuesheet? Maybe I could come up with something general purpose that would allow extracting any desired tag. Hmm... 

WavPack embedding reference

Reply #9
Hm, I think --extract-log is too simple and will only give a benefit when there's only one single log file stored with a specific tag field name in the tag. Automatic extraction will work for most cases (1 cuesheet and 1 log file), but will fail for all more complex tags.

I for example always embed 2 cue sheets and 1 EAC log, and sometimes additional logs in an image. One cue sheet is the original cue sheet as created by EAC, and the other one is for foobar2000 to be edited. Additional logs are for older rips where I didn't have used AccurateRip and where I created AR logs afterwards with another tool.

So when I wanted to use only wvunpack for unpacking the whole CD rip into it's single components, it's not possible. Corresponding command line option to "-w" and "-ww" would be mandatory, IMHO, at least for static methods. Or as I said a real automatic extraction, where multi-line tag fields will be written to text files, named like <basename of the audio file>.<tag field name>.txt. Standard tag fields like "LOG" or "CUESHEET" would be <audio file's basename>.log and <audio file's basename>.cue. As for binary files, I don't know about non-image data, how or if at all it should be handled, but isn't it so for embedded images that the filetype is stored along with the binary data, as well as extra meta information ("front cover", "back cover", etc) in the APEv2 tag?

 
SimplePortal 1.0.0 RC1 © 2008-2018