This is the announcement of Cuesheet Processor (CueProc), the successor of my Audio CD Image Reader (ACDIR) though I'm not sure how many users at hydrogenaudio.org are still using ACDIR. Not having updated ACDIR for over a year, I felt sorry for some users who reported some problems in ACDIR. I was planning to rewrite the tool in Python to simplify the usage (I didn't like the variable syntax in ACDIR), to enhance some features, and to reduce the effort necessary for maintaining the source code. I hope you like this new tool.

Homepage: http://nyaochi.sakura.ne.jp/xoops/modules/...write/tc_6.html
Download URL: http://nyaochi.sakura.ne.jp/xoops/modules/...id=1&lid=14

Cuesheet Processor (CueProc) is a command-line tool for converting audio CD images into another format such as WAV, MP3, Ogg Vorbis, MP4, MPC, WMA, etc. The functions of this tool can be summarized:

• Parse a cuesheet (a .cue or audio file with the cuesheet embedded). Field values in a cuesheet (e.g., TITLE, PERFORMER, REM DATE, etc) will be used by the latter job.
• Read audio data in a CD image (supported format: FLAC, Monkey's Audio, WavPack, WAVE).
• Extract tracks in a CD image to individual WAVE files.
• Execute an external encoder with predefined command-line arguments for each track. CueProc sets appropriate command-line arguments (e.g., naming for output files, tagging, etc) automatically by specifying a codec.
• Execute an external encoder with configurable command-line arguments.
• Send audio stream of each track to STDIN of the external encoder.
• Enumerate cuesheets recursively under a directory.
• Process multiple cuesheets at a time, which is useful for converting an audio collection into a lossy format.
• Skip encoding when the corresponding output file exists, which is useful for converting new CD images only.

Example of CueProc usage:


Pros of CueProc over ACDIR

• Most part of the source code is written in Python. Audio extraction program (getaudio.exe) is written in C/C++ for faster decoding-speed.
• Predefined command-line patterns for Ogg Vorbis encoder (oggenc.exe), LAME MP3 encoder (lame.exe), Fraunhofer IIS MP3 Surround Commandline Encoder V1.2 (mp3sencoder.exe with tag.exe), Helix MPEG Layer III audio encoder v5.1 (hmp3.exe with tag.exe), MusePack encoder (mppenc.exe), Microsoft ® Windows Media Encoder Command Line Script Utility (WMCmd.vbs via cscript.exe), AACPlus v2 Encoder using Winamp 5.3 enc_aacplus.dll (enc_aacplus.exe, mp4box.exe, neroaactag.exe), Nero Digital Audio Reference MPEG-4 & 3GPP Audio Encoder (neroaacenc_sse2.exe, neroaactag.exe).
• Simplified and reasonable syntax of variables and conditions. Variables are now expressed wither ${variable} or $variable. Conditions, #if{condition}-#elif{condition}-#else-#endif are now expressed in Python code snippets.
• Comprehensible variables. Try --show-variables option with your cuesheet to see the list of variable values.
• Full Unicode support internally even though we still can't pass UTF-8 values properly in a command line (without Win32 UTF-8 locale).
• Configurable character encoding (-w option) to parse cuesheets. CueProc can read cuesheet in any character encoding supported by Python 2.5, as well as UTF-8 cuesheets.

Cons of CueProc over ACDIR

• Much larger binary size because it is compiled by py2exe.

If you have any suggestions to this program, write it in this thread or send an email to me.

nyaochi,

Thank you for progressing ACDIR.

REACT uses ACDIR to split images to tracks, so I would say that it has proved very useful to many people, including me.

I actually spotted this on your website a couple of days ago, so it is already included in the wiki cuesheet page. I was contemplating PM'ing you about it but you beat me to the punch thankfully.

Personally I am very happy with the way ACDIR works, and I was wondering what benefit there would be to switching, so, many thanks for the list above. I'll have to take a look to see what additional variables there are.

Thanks again.

I've tried using CueProc to encode Nero MP4 files and I get this error: "WARNING: No suitable output class found".
cueenc -c neroaacenc_sse2 -p "-q 0.53" "soss.cue"

Yet, it worked perfectly with LAME using this cuesheet.
cueenc -c lame -p "-V5 --vbr-new" "soss.cue"

I have all necessary files in my path: Neroaacenc_sse2.exe, Neroaactag.exe. To keep it simple for testing, I placed all files in my E:\DOS directory.

Thanks in advance for the help.

CueProc -c option specifies a codec name, which is like a preset name for an encoder. Codec name and binary name are different for some encoders. If you want to use Nero MP4 encoder, specify:


To see the list of codec names and the information about a codec:

Hi Synthetic Soul,

Thanks for the Wiki page and your effort at this forum (I like your lossless compression page though this is an off-topic ). I was going to write an announcement here when the documentation reaches at some level. I didn't expect that you would find the release at my home page.

Thanks for your great work nyaochi! I am in the process of backing up my entire CD collection to FLAC. I will definitely use your new program.

Thank you, nyaochi!

Also, is there a way to make the extenstion "m4a" instead of "mp4"? I use an iPod, so I must have the "m4a" to play the file.

I released CueProc 1.3 for this enhancement. CueProc 1.3 now has -e (--codecext) option to change the extension of output files from the default one set by the codec.

Thank you again, nyaochi. The -e option is terrific! I was tearing my hair out trying to get the .m4a result through "extpipe", but was unsuccesful.

Two last questions for you, though.
1. If I use "neromp4", am I restricted to the path and filename structure? i.e. "...\neromp4\tracknumber_title.ext"
I tried -o "$tracknumber $TITLE", but CueProc quit before encoding started, so I am assuming that I misunderstood the meaning of the -o option.

2. What option(s) do I use so that I can use a vorbis comment tag cuesheet in my FLAC image?

Thanks a lot for answering my questions so promptly and for working on CueProc.

No. The output directory can be specified by -d option. Please refer to the example (which is default) in cueenc.bat: -d ..\${codec}\${cuesheet_path}. You can modify cueenc.bat for your convenience or overwrite it in a command-line for cueenc.bat.


I can't reproduce this problem although this does not address the above issue.


This was found to be a bug, and CueProc 1.4 was released.

Hi Nyaochi,

I think I may of found a bug in version 1.4. Using the same code as above (3 posts up), the program seems not to be able to run "neroAacTag" correctly. After each encoding I get this message "ERROR: Could not create temporary file.", then "Updating MP4 file... Could not update MP4 file." The file encodes and plays fine, but there are no tags. This happens with a regular cuesheet or the embedded cuesheet in the FLAC image.

Thanks again for your help.

Please spot the cause of your problem exactly. I have no idea about your problem. CueProc will not create a temporary file with 'neromp4' codec.

The task of CueProc is just to generate command-lines for encoding and tagging tracks. For example, CueProc generates the following two command-lines to encode the first track of an album with Nero Digital MP4 encoder:

'getaudio.exe' is a small program, which comes with CueProc, to extract audio stream in an audio file and to send the stream to STDOUT. 'neroaacenc_sse2.exe' will receive the audio stream from STDIN and output an MP4 file. Then CueProc runs 'neroaactag.exe" to set tag values to the output file. CueProc generates these command-lines from a target cuesheet based on a template built in 'neromp4' codec. You can see these command-lines by CueProc -n, (--rehearsal) option. You can test these command-lines manually via the command prompt.

If you found a problem in command-lines generated by CueProc, please let me know which part was wrong and to be fixed. If no problem is found in the command-lines (i.e., CueProc worked correctly at least), I have no idea how to fix it.

Ok nyaochi,

Here's the deal. To test, I used neroaactag to tag one mp4 file created through CueProc and one created from foobar2000, with both programs using the nero standalone encoder. Then I manually tagged each file just -meta:ARTIST. The foobar created file tagged properly, but the one created through CueProc gave the same error as stated in my previous post. So, can I assume that since the files play ok, that something is wrong with the mp4 container during creation?

When I used the -n option, everything in the commandline looked perfect. All tag fields were correct, the path & filename were correct. Both encoder & tagger were listed. Neroaactag does not like the file that is being passed to it.

I am not trying to be a pain in the ass. I'm just letting you know that there is something not right. Everything in this area worked as expected in 1.3, but not in 1.4. I will try again on a different machine and see if I get the same results.

As I wrote before, CueProc does not touch the output MP4 files at all but just lets neroaacenc_sse2.exe encode with some parameters (encoder options, input filename, output filename, etc). I suspect the neroaactag.exe does not like the path/file name of M4A files, but just speculation.

Did you enter the command-lines (encoding and tagging) directly to the command prompt to check the correctness of the command-lines, i.e., to see whether if the command-lines surely write tag information?

Yeah, I know. I just need more information to find out this problem. I can't reproduce your problem in my environment. I have no idea what causes this problem and how to fix this problem with this information.

Are you sure? I think the changes between 1.3 and 1.4 are too small to make the difference. You can download 1.3 for testing:
http://nyaochi.sakura.ne.jp/dist/cueproc-1.3_win32.zip

Hi nyaochi,

Well, I got home from work today and all is well, running on my home computer. My computer at work must have quirks. It was not allowing neroaactag to create it's temporary file for tagging. Thank you for your time and patience. My apologies for driving you crazy!

Hi drbeachboy,

No problem at all. Good to hear that you sorted out the issue.

Hi nyaochi,

I have a question regarding tagging. Currently, I use REACT to encode to a FLAC image, which in turn calls ACDIR to encode and tag tracks with Nero. ACDIR calls neroAacTag, and gives me the option to choose which meta that I want to carry over to my m4a files. Especially BAND, TOTALTRACKS and sometimes COMMENT tags. So the question arises; is there a way to add additional tags in CueProc? Can "extpipe" serve that purpose or is that something that you would have to add to CueProc?

I have CueProc working with REACT, but as expected, my m4a files only get tagged with the 6 standard tags in "neromp4".

Thanks again for all your help and fielding all my questions.

How does CueProc handle pre-gaps? Does it append them to the previous track, does it pre-pend them to the next track or does it ignore them?

I would suggest that it appends them to the previous, as it only deals with 01 indexes. This was certainly true for ACDIR.

I think there are four options to deal with this topic:

1. CueProc tries to maintain a 'guildeline' to use rare tags such as BAND and TOTALTRACKS. In other words, CueProc defines a guideline to use "REM XXX" fields in a cuesheet and to map them to encoded files. Could you provide me with a example of REM fields and their mappings to command-line arguments for neroaactag.exe? I'd like to include this to establish the guidline.
2. Improve CueProc so that it takes arguments for the tagging program as well. Currently, a user can add arguments for encoders with -p option, but can't for tagging programs. I'll address this enhancement in the next release.
3. Use 'extpipe' codec. But I will also revise this option in the next version as I noticed some missing feature to achieve tagging.
4. Modify the source code. It's quite easy to hack the source code to define your own codec.

I will address options 1, 2, and 3 in the next release.



Yes, CueProc assumes INDEX 01 as track boundaries, similarly to ACDIR. Audio stream between INDEX 00 and INDEX 01 of a track belongs to the previous track.

Hi nyaochi,

The tags stated above are not from REM's in the cuesheet, but rather from "PERFORMER" (top one in cuesheet) for BAND (Album Artist) and EAC's options %x for "TOTALTRACKS" and %e for "COMMENT".

In neroAacTag, "TOTALTRACKS" and "COMMENT" are standard meta field names, while "BAND" or "ALBUM ARTIST" would come from the "-meta-user:" command.

As for these tags being "Rare" as you stated above, maybe once upon a time they were, but these days ALBUM ARTIST & TOTALTRACKS are much more commonplace. My album playlists in foobar2000 won't display correctly unless it sees the TOTALTRACKS tag. I use it as the trigger to display "Album" view or "Single" view.

In the end, flexibility and ease of use are the keys to people using programs. I am sure that striking that balance between the two is a tough thing to acheive for you programmers. So, thank you for listening to us, for sharing your programs with us, and for continually trying to make them better. It is very much appreciated!

CueProc 1.5 was released. Changes from 1.4 are:

• Parse a cuesheet (a .cue or audio file with the cuesheet embedded). Field values in a cuesheet (e.g., TITLE, PERFORMER, REM DATE, etc) will be used by the latter job.
• Read audio data in a CD image (supported format: FLAC, Monkey's Audio, WavPack, WAVE).
• Extract tracks in a CD image to individual WAVE files.
• Execute an external encoder with predefined command-line arguments for each track. CueProc sets appropriate command-line arguments (e.g., naming for output files, tagging, etc) automatically by specifying a codec.
• Execute an external encoder with configurable command-line arguments.
• Send audio stream of each track to STDIN of the external encoder.
• Enumerate cuesheets recursively under a directory.
• Process multiple cuesheets at a time, which is useful for converting an audio collection into a lossy format.
• Skip encoding when the corresponding output file exists, which is useful for converting new CD images only.

CueProc 'neromp4' plugin now sets totaltracks, disc, totaldiscs, url, copyright, comment, composer, isrc fields.

As for album artist, I didn't employ any of these as the standard because four different approach to set album artist for MP4 seem to exist at this moment: Tunes' "aART" atom; comment atom with "BAND"; comment atom with "ALBUMARTIST"; and comment atom with "ALBUM ARTIST". I can't force any of these as the standard, not being an MP4 user.

If you want to add "-meta-user:album artist=XXX" only when the target cuesheet is a compilation release, use -s (--setvar) option to set "output_option_tag" variable, which is referred to by any output plugins:
Note:

• By default, COMPILATION variable is set to true automatically when a target cuesheet has multiple distinct PERFORMER names.
• 'output_option_tag' track variable will be evaluated as a pattern template and passed to a tagging program.
• ${quot} or $quot will be replaced with a double-quotation character "

The following is an example of 'extpipe' usage for neroaacencoder:
You can define your command-line patterns to be invoked by CueProc.

Thanks for your work on this tool nyaochi. For the most part it's helped me get around some of the limitations I found with ACDIR. But in running it through its paces, I've come across some new issues. I'm hoping you can shed some light on the situation.

My directory layout is pretty much the same as what you use in the CueProc example. I.e. all images under one directory and all transcoded files under another. So to transcode all FLAC images into MP3s I find all the FLACs

and let CueProc do its thing

With the exception of a few minor tag issues (temporarily resolved with --ignore-tag-errors) the first pass ran through the 1000+ images without a hitch. As CueProc's behaviour (like its predecessor) is to ignore existing files, I intended to run through the process again after adding one or more new images to the images directory. This is, however, where the problem occurred.

Running through the process a second time, CueProc tripped up and stopped relatively early on giving me this error message:


I removed the offending image and all images processed up to that point from cues.txt, and started the process again. A little later, it happened again.


Similar errors occurred a dozen or so times throughout the second pass. Interestingly, all errors were for existing images which had already been transcoded in the first pass. Examining the problem further, track 4 from "Morcheeba - Charango.cue" is

The name of the file produced in the first pass is


But Tag reports the track's details as


The "ã" in the track title has been replaced with an "a". Similar characters substitutions have occurred in the other cases. E.g.

1. • cue sheet: ü
   • file name: ü
   • Tag output: u
2. • cue sheet: ³
   • file name: <blank>
   • Tag output: 3
3. • cue sheet: Â
   • file name: Â
   • Tag output: A
4. • cue sheet: ´
   • file name: ´
   • Tag output: '

Interestingly most other characters with diacritic marks seemed to have got through without issue. E.g. ç and ô. Does anyone know what might be causing this? If you require any additional information, please let me know.

The other minor issue I've found is with genre ID3v2 tags. After modifying the genre field in all the source .cue files to match an item in the "lame --genre-list" output (effectively working around a silly LAME ID3v2 genre tag issue), I still get errors like this

I've seen problems with the genres "R&B", "Folk/Rock" and "Pop/Funk". At a guess I'd say the ampersand and forward slash characters are getting in the way.

On the positive side, messages just appear as warnings and don't kill processing. On the negative side it means tags aren't being properly written to the transcoded files. And seeing as it's not stopping processing, these characters in other fields may well be affecting other types of tags.

Finally, and possibly slightly off topic...

The MP3s produced by this process will almost exclusively be used with an iPod and iTunes. Through posts around HA and my own testing, it seems iTunes can't correctly group tracks from a various artist album using standard tags. It requires the TPE2 "Album Artist" (a.k.a. "Band") tag to be present.

Despite the frame being part of the informal standard, LAME does not seem to support it. Can anyone suggest a command line tool that will do the job as part of the CueProc transcode process? So far the only solution I've seen is to do it all manually through a tool like Mp3tag, The GodFather, or even iTunes itself. All help is greatly appreciated.

Thank you for the detail report of your problem. So sorry for my late reply. I simply forgot about this while I was focussing on other jobs. I released CueProc 1.7 a few days ago.

CueProc assumes the character encoding for cuesheet as CP437 (DOS-US) in your environment. Please specify the character encoding for cuesheet manually by -w option. I'm not sure the correct character encoding for your case, but I guess something like ISO-8859-1. Encodings CP437 and ISO-8859-1 share the same characters for US-ASCII, but have different mappings for characters such as ü, Â, etc.

This is also because the wrong setting for the character encoding.

Oops, R&B should be quoted. I'll fix this.

I wrote two patches for LAME frontend last month.

Adding user-defined ID3v2.3 frame:
http://sourceforge.net/tracker/index.php?f...amp;atid=300290
Albumart (APIC ID3v2.3 frame) patch:
http://sourceforge.net/tracker/index.php?f...amp;atid=300290

Building a LAME binary with these patch enabled, you can use options like:
--tv "TPE2=Any Genre" (User-defined genre name)
--tv TCMP=1 (Compilation flag used by iTunes)
--ti cover.jpg (Writing an albumart image in APIC frame)

I'm going to change the command-line template that CueProc uses for LAME once these patches are integrated in the official release. But I can't employ these options for CueProc at this stage.

Thank you for the time and effort spent on developing this application. I can't stress enough how much I appreciate your work. I'll run 1.7 against my problematic files and report back on how it went.

Your coverart, TPE2 and TCMP tag option extensions to LAME are exactly what I'm looking for. I don't possess the tools or knowledge to build LAME for myself but, if you do, and you're looking for someone to test it along side the planned CueProc template changes, I'd be more than happy to do some testing.

I uploaded the Win32 binary at:
http://www.hydrogenaudio.org/forums/index....showtopic=51781

BTW, the genre frame was "TCON" (I made a mistake in my posts).

I'm pleased to report explicitly stating a character set (ISO-8859-1) with the -w switch processes the previously problematic cue sheets without any issues. In combination with your unofficial LAME build, the command line ended up being

I've got a few questions I'm hoping you can help with.

LAME build
If it weren't for your recommendation not to, I'd transcode my entire collection now using the LAME binary as provided. Aside from the obvious (head code, almost completely raw, no testing, etc.) are there any other reasons not to make use of this build? Could the patch easily be applied to the 3.97 release code? I've noticed compression times aren't particularly quick. Which compile options did you use on the build?

Compilation flag
If I were to transcode my whole collection at the moment, I would need to run CueProc twice:

• once against a list albums with a single performer without "TCMP=1"
• and again against a list of albums with multiple performers with "TCMP=1".

The CueProc help mentions a --no-auto-compilation option. I'm assuming this will work in conjunction with LAME once the functionality has been officially implemented. If so, how would this work with other formats? Can you please elaborate.

Album art existence
Nearly every album in my collection has an album art file (FrontCover.jpg), but there are some that do not. For the one's that don't, I'd like to insert a placeholder image during the process. Can CueProc test for a file's existance? I'd guess that it would resemble this

External metadata tool
Another thread about arbitrary ID3v2 frames (which mentions your LAME patches) discusses the metamp3 tool and the possibility of an "official" metadata tool. Can CueProc make use of an external tool for defining metadata during processing? If so, how would this be achieved with the current version? This may provide a solution for adding compilation tags and album art, as well as replaygain/mp3gain and other arbitrary tags.

Finally, when looking further into the various character encodings the other day, I came across a character encoding auto-detection library written in Python. Might this be something you would consider incorporating into CueProc? Considering the issues I've faced, it may save someone a few headaches

I've just started looking at CueProc as a diversion from problems I was having with acdir in REACT, and it looks very very nice (and nyaochi, you've done a great job evolving it -- THANK YOU!), but this leads me to a feature request.

As a bit of background, I'd like to do a one-pass CD rip that will:

• Rip to a WAV image with cuesheet;
• Decompose the WAV into FLAC tracks in an organized directory hierarchy;
• Decompose the WAV into m4a tracks (using iTunes' native encoder) into an organized directory hierarchy;
• Handle the different format tags properly;
• Add album and track replay gain, and cover art as appropriate;
• Delete the WAV/cuesheet when finished.

Now with REACT I can do most of this if I operate entirely in track mode. REACT uses iTunesEncode to do the m4a track generation, but so far I've found no way to do this with acdir if REACT is in image mode. I'm beginning to think iTunesEncode (via acdir) is not capable of being scripted to be part of an image-based routine.

So the feature request is to let CueProc leverage iTunes' COM model directly (instead of iTunesEncode which is no longer supported, since the source code has been lost, and which may break anyway with a future version of iTunes). Omni Encoder does this already, by the way (but great as it is, OE isn't a one-pass system).

The reason I want to use iTunes' AAC encoding is because of gapless playback on iPods; so far, NERO-encoded AAC will not reliably play back gapless on 5G iPods, and may never (I don't want to get into whose fault this is, since that discussion will not solve anything). And I own many gapless CDs. Lame-encoded MP3 will play gapless on an iPod, but in listening test I've done across my music library, the m4a output (at equivalent encoding rates/file sizes) is often superior to Lame mp3 on the systems through which I play music from the iPod (car, headphones). I've tried tweaking Lame settings, but have found I need to go to 160 VBR to get reliably and noticeably better output to m4a at 128 (and that advantage is offset by the reduction in storage capacity on the iPod). Nero-encoded AAC sounds as good, but still has the gapless problem.

Now I love REACT and while nobody so far (as far as I know) has gotten it to work with CueProc (as a replacement for acdir, which it already works with), my guess is that it's only a matter of not much time before that happens. If CueProc already worked directly with iTunes (similar to how it works with Lame, OggEnc, and WMA, etc.), nirvana would not be too far away!

Thanks, nyaochi, for considering this request!

I really like this tool. Thanks for all the work you've put into it. I had a few issues with it when I first started using it, but all but one of them has been addressed by the various updates and posts here.

The only issue I still have is that the old acdir tool had a switch called '--hidden-track-1' that would cause the audio in INDEX 00 in TRACK 01 to be appended at the beginning of the first track. That switch doesn't seem to work with cueproc and the default behavior of cueproc is to skip the audio from INDEX 00 of TRACK 01. Is there a way around this other than deleting the INDEX 00 line from the cue sheet?

Thanks.

Oops, I should have watched at this thread. Sorry for the late reply as always...


MSVC2005. I don't have the latest version of Intel C++ compiler and can't provide the faster compile. Please ask, for example, john33 to build LAME binary with these patches enabled. I'm reluctant to distribute a LAME binary because it may be illegal to distribute an MP3 encoder due to the patent issue in my country and because I can't provide 'guranteed' service of maintaining the binary.


The current CueProc issuees a compilation flag automatically with "nero_ap" and "oggenc". Unfortunately, it does not issue the flag to LAME encoder. This is because we need a LAME binary with the patch (user-defined ID3v2 frame) enabled, but it's not integrated to the official. I hope the patches to be integrated to the official, but it's up to the decision of LAME developers. I'm aware that the patch for albumart may be a bit problematic for them.

As for the other formats, please suggest me if you know the specification (or custom) to set compilation flag.


I'll consider this.


Yes, it's possible although you need to change the source code. I will evaluate metamp3 tool for the possibility of using from CueProc.


In my opinion, those who use CueProc should be intellectual enough to be aware of the character encoding of a cuesheet. I will evaluate the library later, but the auto-detection of character encoding does not always work well. I guess the library leverages HTTP header and meta information to detect a character encoding.

We don't have to integrate CueProc with iTunes COM interface. IMHO someone using iTunes should develop and maintain a command-line tool. If only a command-line tool (with STDIN input if possible) exists, I can write a module for the tool.


Yeah, I understand that's a big reason.


Thanks for the suggestion. Please let me know if there's a good command-line tool for iTunes.


I'll implement this in the next version. It may take time as I will have a business trip for two weeks from this Friday.

Hi,

I'm trying to use Cueproc to split Wavpack images into Nero AAC tracks. Using the default "-c neromp4" option does what I want except for the filename and the comment. The filename is easily changed by adding "--outputfn=$track - $title - $artist", but I can't figure out how to modify the comment. At the moment, Cueproc writes the comment from the cuesheet. Instead, I want "%date% NeroAAC Q0.35" (i.e. current date followed by encoder settings). Can ayone help?

Thanks for the programme.

Stephen

I think -s (--setvar) option, which allows you to change values of any variables, should work. Please try:

This will overwrite the value of COMMENT variable set by CueProc based on the content of a cuesheet.

I'm now traveling abroad and can't test it by myself though.

Thanks for your response to my earlier post, nyaochi. I realize you are a busy guy so I patiently await the next update of cueproc. It's a great tool.

In the meantime, I have noticed two other minor behaviors of cueproc that you might want to have a look at when you get the opportunity. I have been experimenting with using cueproc for splitting to flac and wavpack formats using the -extpipe switch, and that's where these behaviors have come up, as follows:

1. Your website refers to the variable 'NUMTRACKS'. Within my tagging code, I have tried using the following code:

--tag=TOTALTRACKS=$quot${NUMTRACKS}$quot [for flac output]
-w ${quot}TOTALTRACKS=${NUMTRACKS}$quot [for wv output]

In both cases I get an error message that cueproc doesn't like the key 'NUMTRACKS', and the program aborts. But when I change numtracks to TOTALTRACKS in the above code, it works perfectly. The long and the short of it is I think your website just needs to be updated to show that the correct variable name is TOTALTRACKS, not NUMTRACKS.

2. Skipping existing files - This is supposed to be the default behavior of cueproc but it doesn't seem to work properly when making flac or wv files using the -extpipe switch. (It does, however, work as expected on the built-in lossy formats that I have tested, namely LAME, OGG and NeroAacEnc.)

In the case of flac and wavpack, I get an error message from the FLAC or WAVPACK executable saying that the file already exists. It's not a big problem, as Wavpack allows the user to tell it whether to overwrite the file or not, and Flac skips it and goes on to the next track. However, I would have expected that cueproc would itself skip a file that already exists and not even invoke flac.exe or wavpack.exe, as that seems to be how it functions with the built-in lossy codecs I have used.

In addition, there is a delay after flac.exe and wavpack.exe give the error messages. I suspect that cueproc is busy extracting the audio which is then being ignored by the codecs, because it seems that the delay lasts about as long as it takes to encode the track when I delete the existing output file and start from the beginning. I'm guessing, but I suspect this behavior might have something to do with the lack of built-in file extensions when using -extpipe. (I haven't been using the -e switch to set the extensions on flac and wavpack files since your website and posts here indicate that's not how to do it. Instead, I have been using code such as "-o $quot${output}.flac$quot" within the -m switch. This code works as expected.)

Neither flac.exe nor wavpack.exe has a switch forcing the codec to skip existing files, so I have to rely on cueproc to handle this. (They do have switches to force overwriting existing files, but that's not what I want to do).

It sure does. Thanks, Nyaochi.

I think I have found a more serious bug when encoding to LAME. I discovered that a number of LAME files that I made with cueproc had bad headers according to mp3val and mp3guessenc. In each case, the mp3 file was misreporting its size by about 300 bytes bigger than it should have been. Fixing the headers with foobar2000 eliminated the problem but the LAME headers are now completely gone. I've been using lame 3.97 32-bits on Win XP.

I believe I have traced the problem to the way cueproc passes tagging commands to lame.exe. I did a work around and set cueproc to encode using the pipe, i.e. -c extpipe instead of -c lame. When I set lame to not tag the output files, they come out fine. Both mp3val and mp3guessenc report no errors. But when I duplicate the tagging of the -c lame switch I get the errors again, although they are slightly different in size depending on the precise tag parameters I use. I haven't managed to narrow down whether a particular tag command is causing the problem.

Has anyone else noticed this problem?

How is the problem related with CueProc? The task of CueProc for lame is just to pass appropriate command-line parameters and to send the audio data to the pipe. What if you split tracks into WAVE files and enter the same command-line to LAME manually?

I have MP3 files encoded by CueProc and LAME3.98 (alpha) with no error reported by mp3guessenc.

Despite the previous character encoding issues I've had, CueProc's "--find" feature has always worked for me without incident. But when I recently tried to enumerate a list of cue sheets, I received a familiar error
The file/path that causes the error is
As I haven't touched any system level configuration on my machine recently, I can only assume a Windows update may be at fault. I have also tried explicitly stating several system character sets with the "-W" switch (e.g. ISO-8859-1, windows-1252, utf-8) but they all produce the same result.

Redirecting the output of Windows' own "dir" command also garbles the path names so I'm running out of ideas. Any help in the matter is greatly appreciated.

This is the list of items I'm going to fix/add in CueProc 1.8. I think this list covers all reports/suggestions from users so far. The next release will be around the first of April. Please let me know if you have more reports/suggestions that are not included in the list.

CueProc 1.8 (2007-0x-xx):

[done]
- Support LAME with Nyaochi's patches applied as 'lame_nyaochi' encoder. This encoder supports albumartist, bpm, composer, copyright, disc-number, total-discs, and compilation variables.
- CueProc detects cover.jpg, albumart.jpg, or folder.jpg file as the albumart image. By default, CueProc willset ALBUMART variable if either of these files exists in the cuesheet directory. You can disable this feature by --no-auto-albumart option. CueProc does not overwrite ALBUMART variable if it is specified in the cuesheet.
- The batch file cueenc.bat now supports arguments more than 9.
- Support FLAC encoder
- Support WavPack encoder
- New option to configure the list of albumart filenames
- Fix ISO-8859-1/IBM-DOS encoding problem (in filenames described in cuesheet, --find command)
- New option: --hidden-track1 to include INDEX 00 of the first track

[Not a bug]
- Checking existence of an output file with 'extpipe' encoder
Wrong (CueProc tests the existence of output files by ${output}, but ${output} does not contain the extension ".flac"):
Correct (${output} will contain the extension ".flac"):


[planned]
- All done.

[deferred]
- Integration with metamp3 tagger. As I reported in this post, I couldn't use metamp3 program to tag MP3 files with multi-byte characters (e.g., Japanese). I'll wait for this bug to be fixed.

I just did some testing with lame 3.97 and lame 3.90.1 converting wave files on the command line. I set each up to apply tags. In both cases, mp3val reports that the mp3 files being produced are misreporting their size by about 300 bytes too many. So you are right, nyaochi. The problem isn't cueproc, it's lame.

Until I started using cueproc I never let lame.exe tag my files, so I've never had any reason to notice this problem before. I am amazed that with all the testing that lame receives and all the people here who use lame to apply tags from EAC, that a problem like this would crop up now.

Fantastic news nyaochi. I look forward to the release.

As per your recommendation, I've been in contact with John33 and he's put together a build incorporating your patches. I'm putting it through its paces at the moment and, if all goes well, he'll make a (semi-)formal release soon. I'm keen on the new CueProc functionality which will tie in with your patches. In addition to what you've listed, I'd like to request the following:

Conditional Album Art Processing
Mentioned in one of my earlier posts, conditional processing for album art files would be very useful. Some examples I can think of are:
testing for a file's existence and adding only if true
testing for a file's existence and inserting a placeholder image if false
setting order of precedence if multiple file names exist in the folder
Automatic Compilation Detection
Using the future "lame_nyaochi" encoder, I assume the implementation for this will be something likeI also assume the "--no-auto-compilation" will override this behaviour. Can you please confirm the implementaion.

Thanks again. If you require any assistance testing pre-release versions, please let me know.

I've just run MP3val against my transcoded MP3s and, exactly as you mentioned, MP3val states there are the wrong number of bytes in each of the files' headers. However, since it merely passes parameters to the selected encoder, I hardly think this is CueProc's fault. To be sure, I manually ran the conversion command for a single file as CueProc would have produced. MP3val also reported this MP3 as having the same header problem.

Personally, the audio and meta data produced by LAME 3.97 (and later) have never caused any problems for the playback applications/devices I use (foobar2000, iTunes, iPod). Aside from MP3val, have you had any playback applications/devices report issues with the files?

I edited my post which you quote (thinking no one had read it yet), to indicate that I did do some testing and managed to demonstrate that it is indeed lame and not cueproc that is causing the problem.

Like you, I haven't noticed any playback problem with these particular files when I play them in foobar2000. But I do find it disconcerting that lame's tagging routines are causing an error in the headers that no one has ever noticed before.

Thanks for the deeper investigation and clarification.

Thanks. I've just bought an MP3 player that displays an albumart image embedded in an APIC frame and come to want a faster compile of the binary.

As for the conditional album art processing, you can write such condition within #if{} bracket even with the current version if you are familiar with Python. Python has a function to test the existence of a file, e.g., #if{os.path.exists('cover.jpg')}. But you will need to a trivial code to concatnate the path to the cuesheet before the filename. The current CueProc also supports #if ... #elif ... #elif ... #endif syntax. So what you wanted to do is already achieved by the current CueProc.

However, I'm also aware that ordinal users are not so familar with Python. The idea of automatic cover-art detection is to eliminate such coding efforts for non-programmers. If you have an preferable ordered (prioritized) list of file names for albumart, please let me know. Maybe "frontcover.[jpg/png/gif]", "cover.[jpg/png/gif]", "albumart.[jpg/png/gif]"?

CueProc fires a compilation flag only if two or more distinct artist names exist in tracks in a cuesheet.

Digging through LAME's "--longhelp", I noticed this switch
Unfortunately adding the switch still does not produce files MP3val is happy with. Worse still, I found most of the files to be at least a few hundred kilobytes more bloated than when I didn't use the switch. If a bug hasn't been filed already, and it's something that's concering youn, this might be one to mention to the LAME devs.


John and I have had a few back-and-forths now, and we're certainly getting close. In my testing I found that JPEG and PNG files work fine but GIF files cause some issues. LAME happily accepts a GIF at encode time without throwing up any errors, but iTunes makes it appear as though nothing has been added (so far it's the only tool I've used to test this.) I've had a look your patch and noticed the mime detection looks for "GIF8", which should cover GIF87a and GIF89a files. If there are some particular GIF files you want me to test, or GIFs produced by a particular application (I've been using IrfanView and the Windows Picture Viewer), please let me know. Otherwise it might be worth contacting John direclty.

Incidentally, which MP3 player did you recently purchase?


I've played around with Python in the past and, more recently, when trying to find a relatively simple solution for enumerating *.cue files. Now that I know additional code can be injected into CueProc at runtime, I should be able to sort out a solution. Just to clarify, is this possible with both the py2exe build and the source scripts?

I'd chance a guess that anyone using this tool is likely to be a "power user" and has the knowledge of at least some basic principles in conditional logic. That said, you are right to make CueProc's use as simple as possible. I personally do not have a need for prioritised cover art detection; but it would definitely be useful. I can only guess as to how you would implement this feature but might I suggest either:

1. A command line switch with comma delimited parametrs in order of precedence e.g.
   
   CODE
   --albumart Frontcover.jpg,cover.jpg,albumart.jpg
2. An external text file(most likely residing in the CueProc program directory) containing file names in order of precedence. The text file would only be read if an album art switch is included. File names could be comma/semicolon delimted or on separate lines.

The only other album art file name candidate I can suggest is "folder.jpg", which is used both by Windows and SlimServer (as a defult).

Actually, I did test with JPG files but didn't with PNG and GIF files. I didn't realize the patch was incomplete with GIF files. Thank you for testing and debugging the patch.

iriver X20 (sold only in Japan at this moment?) Recent iriver players (E10 and Clix2 maybe) support APIC ID2v2 frame.

It should be. I'll test before releasing the next version though.

I'll include "folder.jpg" and also add the option to specify the list.

CueProc 1.8 is out.

ChangeLog:

• Support LAME with Nyaochi's patches applied as 'lame_nyaochi' encoder. Please obtain lame.exe with these patches applied at RareWares (thanks john33 for hosting this binary). This encoder supports albumartist, bpm, composer, copyright, disc-number, total-discs, and compilation variables as well as the standard LAME encoder.
• CueProc detects cover.jpg, albumart.jpg, or folder.jpg file as the albumart image. By default, CueProc will set ALBUMART variable if either of these files exists in the cuesheet directory. You can disable this feature by --no-auto-albumart option. CueProc does not overwrite ALBUMART variable if it is specified in the cuesheet.
• The batch file cueenc.bat now supports arguments more than 9.
• Support FLAC encoder as 'flac' encoder.
• Support WavPack encoder as 'wavpack' encoder.
• New option, --albumart-files, to configure the list of albumart filenames.
• New option, --hidden-track1, to assume the first track to begin at INDEX 00 (or PREGAP).
• Fixed incorrect character-encoding problems in some places (e.g., for file names, --find option).

Very short instruction for obtaining MP3 files with albumart images:
1. Save albumart images as folder.jpg in the same directories as cuesheets.
2. Download lame.exe with my patches applied from Rarewares ( http://www.rarewares.org/mp3.html ).
3. Specify "-c lame_nyaochi" instead of "-c lame" in the command-line for cueenc.

I hope that the character encoding problems are solved with this release.

Thanks for the update, nyaochi.

Thanks for your work nyaochi. I've not given any of the new functionality a try yet, but cuesheet enumeration with the --find switch is still causing issues. The error output is similar to to version 1.7

As before I've tried specifying ISO-8859-1 with the -W and -w switches to no avail. Are any new switches/parameters required for this to work?

UPDATE: Unfortunately it's not just file enumeration that's affected. I've had a chance to test 1.8 with a manually populated target file and it produces similar errors; even with -W and -w switches.

Is there a way of copying over the cover art if there is any in the source directory to the destination directory? I don't want to have it added to the tags, just copied over. I can do it by hand, but it would save alot of time when doing all my cd's with the list.txt command.