Skip to main content
Topic: Cuesheet Processor (CueProc) (Read 61026 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Cuesheet Processor (CueProc)

Reply #25

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 "TCON=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.

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). 

Cuesheet Processor (CueProc)

Reply #26
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
Code: [Select]
cueproc -c lame -p "-V2 --vbr-new --ignore-tag-errors --ti $quot$cuesheet_path\FrontCover.jpg$quot" -d "..\Compressed\$cuesheet_path" -o "$TRACKNUMBER $ARTIST - $TITLE" -w ISO-8859-1 --target=cues.txt

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
Code: [Select]
--ti #if{exists('FrontCover.jpg')}FrontCover.jpg#else<placeholder image>.jpg#endif

External metadata tool
Another thread about [a href='index.php?showtopic=51331']arbitrary ID3v2 frames[/a] (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 

Cuesheet Processor (CueProc)

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

Cuesheet Processor (CueProc)

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

Cuesheet Processor (CueProc)

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

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?

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.

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.

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.

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
Code: [Select]
--ti #if{exists('FrontCover.jpg')}FrontCover.jpg#else<placeholder image>.jpg#endif

I'll consider this.

External metadata tool
Another thread about [a href='index.php?showtopic=51331']arbitrary ID3v2 frames[/a] (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.

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

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 

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.

Cuesheet Processor (CueProc)

Reply #30
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).

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.

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.

Yeah, I understand that's a big reason.

Thanks, nyaochi, for considering this request!

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

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?

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.

Cuesheet Processor (CueProc)

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

Cuesheet Processor (CueProc)

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

I think -s (--setvar) option, which allows you to change values of any variables, should work. Please try:
Code: [Select]
-s "COMMENT=$DATE NeroAAC Q0.35"

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.

Cuesheet Processor (CueProc)

Reply #33
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).


Cuesheet Processor (CueProc)

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

Cuesheet Processor (CueProc)

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

Cuesheet Processor (CueProc)

Reply #37
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
Code: [Select]
C:\Music\Images>cueproc --find *.cue > cues.txt
Cuesheet Processor (CueProc) Version 1.7 Copyright (c) 2006 by Nyaochi

Traceback (most recent call last):
  File "cueproc.py", line 552, in <module>
  File "cueproc.py", line 228, in find
  File "ntpath.pyc", line 334, in walk
  File "ntpath.pyc", line 334, in walk
  File "ntpath.pyc", line 334, in walk
  File "ntpath.pyc", line 328, in walk
  File "cueproc.py", line 224, in find_callback
  File "codecs.pyc", line 303, in write
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 24-26: invalid d
ata

The file/path that causes the error is
Code: [Select]
C:\Music\Images\Albums\Gotan Project\LunĂ¡tico\Gotan Project - LunĂ¡tico.cue

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.

 

Cuesheet Processor (CueProc)

Reply #38
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"):
Code: [Select]
cueenc -c extpipe -m "flac -o $quot${output}.flac$quot" CDImage.cue
Correct (${output} will contain the extension ".flac"):
Code: [Select]
cueenc -c extpipe -e .flac -m "flac -o $quot${output}$quot" CDImage.cue


[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.

Cuesheet Processor (CueProc)

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

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.

Cuesheet Processor (CueProc)

Reply #40
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
Code: [Select]
#if{exists('FrontCover.jpg')}FrontCover.jpg#endif

testing for a file's existence and inserting a placeholder image if false
Code: [Select]
#if{exists('FrontCover.jpg')}FrontCover.jpg#else<placeholder image>.jpg#endif

setting order of precedence if multiple file names exist in the folder
Code: [Select]
#if{exists('FrontCover.jpg')}FrontCover.jpg
#elseif {exists('cover.jpg')}cover.jpg
#elseif {exists('folder.jpg')}folder.jpg
[etc.]
#endif

Automatic Compilation Detection
Using the future "lame_nyaochi" encoder, I assume the implementation for this will be something like
Code: [Select]
for Track in Tracks
  if (Track.ALBUMARTIST != Track.ARTIST)
    addParam(--tv TCMP=1)
I 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.

Cuesheet Processor (CueProc)

Reply #41
I don't know that the problem is caused by cueproc for sure. That's why I asked if anyone else had experienced it. The problem could reside entirely with how lame.exe applies tags. I never use lame.exe to apply tags to files except with cueproc so I'm not set up to test whether lame.exe is the problem.

However, I tested cueproc again using a different lame binary, an old 3.90.1 binary that I still had, and I got the same header problem. So if cueproc isn't causing it, then I'm baffled. I'll just use the workaround I mentioned above and forget about it. I'm perfectly happy to tag the files with mp3tag anyway.
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?

Cuesheet Processor (CueProc)

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

Cuesheet Processor (CueProc)

Reply #43
The problem isn't cueproc, it's lame.
Thanks for the deeper investigation and clarification. 

As per your recommendation, I've been in contact with John33 and he's put together a build incorporating your patches.
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.

Cuesheet Processor (CueProc)

Reply #44
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.
Digging through LAME's "--longhelp", I noticed this switch
Code: [Select]
--strictly-enforce-ISO   comply as much as possible to ISO MPEG spec

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.

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.

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?

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]"?

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:
  • A command line switch with comma delimited parametrs in order of precedence e.g.
    Code: [Select]
    --albumart Frontcover.jpg,cover.jpg,albumart.jpg
  • 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).

Cuesheet Processor (CueProc)

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

Incidentally, which MP3 player did you recently purchase?
iriver X20 (sold only in Japan at this moment?) Recent iriver players (E10 and Clix2 maybe) support APIC ID2v2 frame.

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?
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.

Cuesheet Processor (CueProc)

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

Cuesheet Processor (CueProc)

Reply #47
Thanks for the update, nyaochi.

Cuesheet Processor (CueProc)

Reply #48
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
Code: [Select]
Traceback (most recent call last):
  File "cueproc.py", line 599, in <module>
  File "cueproc.py", line 250, in find
  File "ntpath.pyc", line 334, in walk
  File "ntpath.pyc", line 334, in walk
  File "ntpath.pyc", line 334, in walk
  File "ntpath.pyc", line 328, in walk
  File "cueproc.py", line 246, in find_callback
  File "ntpath.pyc", line 102, in join
  File "encodings\utf_8.pyc", line 16, in decode
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 24-26: invalid data

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.

Cuesheet Processor (CueProc)

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

 
SimplePortal 1.0.0 RC1 © 2008-2018