psibre / cuelib Goto Github PK

Right now cuelib doesn't perform any logging. We are already seeing the
need for logs (issue 5) and this need is likely to increase. Rather than
solving these needs on a case-by-case basis, they should be handled in a
structured fashion.

Of the various logging frameworks, jdk 1.4 logging is the only one that is
present in all java 5 installations. Since it offers all functionality that
we are likely to need, and we would prefer to minimize the dependencies on
other software, it is our most desirable choice.

Cuelib is currently tested entirely by hand. This is error-prone and
labour-intensive. We should be using unit tests.

The de facto standard framework for unit tests in Java is jUnit. I see no
reason to use another framework (and no reason to not use a framework), so
we should probably use it as well.

After cutting a file into tracks, TrackCutter should be able to produce a
cue sheet that references the newly created (track-based) files instead of
the original multi-track files.

Cuelib currently ignores comments altogether. It may still be useful to
process and generate comments. This enhancement should include support in
the parser, CueSheet data structure, serializers, XML Schemas, and XSLTs.

CueParser uses a custom parser. While flexible, this is error-prone and
hard to maintain. Perhaps it would be better to use a parser based on a
formal grammar.

This is an open issue. The solution was undecided at the moment this issue
was registered.

TrackCutter does not support some popular file types, such as mp3 and FLAC
files. In order to remedy this, we should take advantage of external
processors. This issue focuses on lossless formats such as FLAC. Another
issue will cover lossy formats.

To handle lossless formats, TrackCutter should call an external
preprocessor that can convert the format to a format that TrackCutter
supports, such as WAVE. The user must supply TrackCutter with templates for
calling the external application, as well as a configuration for matching
processors to files (e.g. use flac.exe for FLAC files and unzip for
wav.zip), and per template the output type of the preprocessor (WAV, AIFF,
etc.)

Cuelib uses Java 6 features, but it should be Java 5 compatible. We should
build cuelib against a Java 5 JDK to ensure that it is Java 5 compatible.

TrackCutter does not support some popular file types, such as mp3 and FLAC
files. In order to remedy this, we should take advantage of external
processors. This issue focuses on lossy formats such as mp3. Another issue
will cover lossless formats.

It is not recommended to convert lossy formats such as mp3, as this is
likely to degrade quality. For these formats, TrackCutter should be able to
call upon external cutters, which it must supply with the necessary
information from the cue sheet. The user must supply a template for calling
the external cutter.

Currently, TrackCutter operates silently. It should be able to print
progress information to stdout and/or stderr. This is particularly
desirable when processing large numbers of files.

Ideally, both stdout and stderr should be supported. Messages to either
channel should only be printed when this behaviour is activated via a
command line option.

TrackCutter can only handle audio files. Therefore it should skip BINARY
and MOTOROLA files. Perhaps a flag should be added to override this
behaviour, as some application may register some audio files as one of
these types. (I.e. since Ogg Vorbis isn't WAVE, AIFF, or MP3, it may be
registered as BINARY.)

CueSheetToXmlSerializer can serialize a cue sheet representation to XML.
Currently, there is no convenient way back. This could easily be done by an
XSLT.

TrackCutter can be configured with a post-processing command. In this
command, one can make references to metadata from the cue sheet. For
instance, the post-processing command can be "c:\tool\tool.exe <title>". If
the title from the cue sheet is "Thriller", "c:\tool\tool.exe" will be
called with the parameter "Thriller".

The problem is that TrackCutter normalizes these metadata fields as though
they were file names. For instance, the character '/' will be converted to
'_', as '/' could cause problems when used in a file name.

This behaviour is unnecessary and undocumented, so should be removed.

We should have a schema that describes the output of CueSheetToXmlSerializer.

TrackCutterCommand will accept a list of cue sheet files. This is
inconvenient when handling large numbers of files, particular when using
fairly primitive shells, such as the default shell under Windows XP.

I'd like the following features to be added:
  * Recurse into subdirectories.
  * Use a specific directory as base directory.
  * Process any file that matches some regular expression.
  * Process any path that matches some regular expression. (Ideally, with
pruning to eliminate branches that could never be matched. That would be
hard though, as we couldn't simply use the standard java regex functionality.)

CueParser warning texts are currently hard coded. This is undesirable as it
makes localization cumbersome. As per best practices, these messages should
be put in a ResourceBundle.

Right now TrackCutter can only read cue sheet files. In scripting
applications it can be useful if the cue sheet can also be read from
standard in.

Cue sheets accept any string as a value for the genre field. (Technically,
it must be a maximum of 80 characters.) However, some applications can
handle only the genres as specified in the ID3 1(.1) spec. TrackCutter
should be able to strip nonconformant genres.

TrackCutter should be able to accept xml cue sheets, such as are produced
by CueSheetToXmlSerializer.

Exact Audio Copy has an option to product non-compliant cue sheets
(http://wiki.hydrogenaudio.org/index.php?title=EAC_CUE_Sheets). It would be
useful if cuelib supported these.

The impact for this change would be relatively high, as the current cue
sheet data structure cannot model such a non-compliant sheet. This issue
will need further investigation.

Not (all members of) all classes have javadoc comments. Make sure that they
have.

What steps will reproduce the problem?
1. Take cue sheet with Russian or other language content
2. Try to parse using the library
3.

What is the expected output?
Parsed result in national characters

What do you see instead?
Line unparseable warnings

What version of the product are you using?
1.2.1
On what operating system?
Arch Linux


Please provide any additional information below.
I have fix for the problem by subclassing line reader and provide charset 
decoding in lines, modified code is available in music-barrel project.

TrackCutter accepts many parameters, and some of these parameters can
become quite long. Since many parameter will often be reused, it would be
useful if these could be configured though a properties file, avoiding have
to retype them each time.