flac dev - Jan 2013 - Bug or strange behaviour or --output-prefix

Hi all,

I was busy programming a tool to automatically run some tests to update 
the FLAC comparison page (http://xiph.org/flac/comparison.html) when I 
stumbled across some weird behaviour of the flac program. So I compiled 
from git and it seems that this bug still is there. As I don't have any 
experience on coding C and don't know which bug-report facility to use, 
this seemed the right spot.

Anyway, I wanted flac to decode some file to another directory than the 
current. The man page says I should use --output-prefix for that, but 
that doesn't seem to work correctly. For example

flac -d --output-prefix ../ somefile.flac

seems to work fine, just as expected. However, the next example

flac -d --output-prefix ../ somedir/somefile.flac

doesn't work as expected. the FLAC utility seems to try to decode to the 
directory ../somedir which doesn't exist. Even using absolute paths do 
not work. For example

flac -d --output-prefix /home/someuser/ /home/someuser/somedir/somefile.flac

it seems that it is trying to encode to 
/home/someuser/home/someuser/somedir/somefile.flac. This can't be the 
intended behaviour right? Now I think of it, what I expected was similar 
behaviour to something which I would call --output-directory. The way 
this is coded looks like a quick fix, but to me it seems this is only 
useful when one has to use a file in the current working directory or in 
some special cases where identical directory trees are used.

So the question is, is this intended behaviour or a bug? If it is 
intended, an --output-directory parameter would be useful for scripting.

Seems like what you really want is an --input-prefix parameter.
You might also like a --create-output-directories option.

In all cases except absolute paths, the input prefix must be assumed  
to be the current working directory. Therefore, any relative paths in  
input file names must be preserved on output to avoid collapsing  
multiple source directories into a single output directory, with the  
subsequent danger of multiple files with the same name overwriting  
each other.

In the case of absolute paths (and even in some of your other  
examples), you seem to be expecting the program to do some sort of  
automatic analysis of the input prefix, output prefix, and relative  
file paths to look for and eliminate overlapping sub-paths. That's  
something that simply isn't done in Unix command-line utilities, at  
least not in any way like what you describe or imply as desirable.


This is basically the long way of saying that the behavior you see is  
by design - it's intended - and you'll find that all Unix utilities  
work the same way. There is nothing to fix here, although some new  
features might get you what you want.


For example, --input-prefix would allow you to use

flac -d --input-prefix somedir --output-prefix ../ somefile.flac

or

flac -d --input-prefix /home/someuser/somedir --output-prefix /home/ 
someuser somefile.flac

(and don't forget that all variations and combinations of options  
must continue to work predictably when more than one FLAC file is  
given. I often process *.flac in large directories.)


For the second example, --create-output-directories would allow you  
to use any of the examples you gave without having flac stop with an  
error when the output directory structure does not already exist.

Brian Willoughby
Sound Consulting


On Dec 18, 2012, at 07:58, Martijn van Beurden wrote:
> I wanted flac to decode some file to another directory than the
> current. The man page says I should use --output-prefix for that, but
> that doesn't seem to work correctly. For example
>
> flac -d --output-prefix ../ somefile.flac
>
> seems to work fine, just as expected. However, the next example
>
> flac -d --output-prefix ../ somedir/somefile.flac
>
> doesn't work as expected. the FLAC utility seems to try to decode  
> to the
> directory ../somedir which doesn't exist. Even using absolute paths do
> not work. For example
>
> flac -d --output-prefix /home/someuser/ /home/someuser/somedir/ 
> somefile.flac
>
> it seems that it is trying to encode to
> /home/someuser/home/someuser/somedir/somefile.flac. This can't be the
> intended behaviour right? Now I think of it, what I expected was  
> similar
> behaviour to something which I would call --output-directory. The way
> this is coded looks like a quick fix, but to me it seems this is only
> useful when one has to use a file in the current working directory  
> or in
> some special cases where identical directory trees are used.
>
> So the question is, is this intended behaviour or a bug? If it is
> intended, an --output-directory parameter would be useful for  
> scripting.

On Tue, 1 Jan 2013 18:59:20 -0800
Brian Willoughby <brianw at sounds.wa.com> wrote:
> Seems like what you really want is an --input-prefix parameter.
> You might also like a --create-output-directories option.
[...] 
> This is basically the long way of saying that the behavior you see
> is by design - it's intended - and you'll find that all Unix
> utilities work the same way. There is nothing to fix here, although
> some new features might get you what you want.
At some point pretty close to here you decide what you really need is a
script which implements the particular behaviour you want, calling flac
for each file it finds, and doing any other housekeeping like directory
creation. Such a script will never be generic however, because it will
depend on the workflow and environment you want to use it in.

Richard