Converting DASHhigh to FLAC with ffmpeg

[Jeremy Nicoll - ml gip]

On 2017-01-25 00:04, Budge wrote:

> 
> I am certain I shall not be able to hear the differences if a young
> chap like you cannot.  When I find out how, in detail, I shall try
> converting some samples to mp3 and thanks for the further nudge in
> that direction.

I installed the 'lame' converter.  I wanted it specifically for 
converting WAV
files to MP3 which is its default behaviour; there are options though to 
tell it
that input files are other things, but I don't know if they include 
whatever you
would be using as input.

If you use linux I should imagine there will be a suitable package; for 
Windows
one can either find source on Sourceforge and compile it yourself (which 
I didn't
want to do) or find precompiled binaries.  I did the latter.

I got it at: http://www.rarewares.org/mp3-lame-bundle.php

One downloaded, I unpacked the zip.  It contained the important parts: 
lame.exe
(which is the command line tool), lame_enc.dll (which does the work and 
can also
be invoked by other .exe's that know it exists to do encoding on their 
behalf), &
a load of CSS & HTML help files.


I put the whole lot in a named folder on my system so I could create 
commands that
would use the specific version I'd downloaded, or - perhaps in future - 
use a
different version, keeping those versions apart.   On the other hand you 
could just
put lame.exe and lame_enc.dll in some folder that is on your PATH.

Once you've done that, issuing

   lame -?

eg as

C:\>lame -?

in a command window should show you help information on how to use it.  
Obviously you
can also look at the html files in the unzipped thing you downloaded, 
but making sure
the command line help works is sensible, as it shows that other command 
line lame
commands are likely to work too.


The commands I use generate 'cbr' ie 'constant bit rate' files.  That's 
to say, every
portion of the audio in such a file is encoded at the same bit rate, 
regardless of the
complexity of the music present in it.  It's possible also to use 
variable bit rate,
where simpler music is stored at lower bit rates, but one of the 
drawbacks of that is
that it's impossible to determine a file's playing time from its size in 
bytes.

Bit rate is specified by: -b nnn    eg -b 320    for 320 kbps.

Also apart from specifying the bit rate I want the result files to have, 
one can tell
lame to do the conversion as quickly as possible or to take its time and 
be as careful
as possible, or pick some intermediate point.  I always use the 'slow & 
careful' option
as with a fast computer time isn't a problem.  That's: -q 0

I like to see any useful info that a command might produce, so: 
--verbose


The basic command then becomes, say

   lame.exe --cbr -b 320 -q 0 --verbose "path\to\input\file.wav" 
"path\to\result.mp3"


In my case, isssuing lots of these commands from a script I also knew 
for each one what the
'track' number, title etc for each result file should be in mp3 tag 
terms. The command for
tagging the result files at the same time is more complicated, eg:

   lame.exe --cbr -b 320 -q 0 --verbose --id3v2-only
        -ta "name of choir"
        -tl "name of concert"
        -tg Classical
        -ty 2015
        -tt "song title"
        -tn 23
        "path\to\input\track23.wav" "path\to\result\track23.mp3"

- though that was all on one long command line.  The  --id3v2-only  
forced lame to define only a
particular type of mp3 ID tag in the result files; -ta, -tl etc defined 
what in MP3 terms are
the 'artist', 'album', 'genre', 'year', 'track title' and 'track 
numnber'.  Those concepts
don't fit classical music all that well and I chose values that would 
make sense in an average
choir member's mp3 player/app.   Note that while most of the values are 
enclosed in double quotes,
the 'genre' isn't because 'Classical' is a genre subtype that lame knows 
about; also values
that are numeric like year and track number do not need to be in quotes.


The scripts I used to build and issue these commands were quite 
complicated as they had to
be able to determine the names of the input files and derive names for 
output files; some
of my files were for individual items in a concert while others were for 
a sequence of
movements in a longer piece and both file names and track numbering 
reflected whether a
file contained single items/movements or multiples.


[The files that I fed in to this process had been chopped up from the 
original recordings using
another command line utility, 'sox', which allows one to do many of the 
things that most people
use a GUI-based seditor like Audacity to do, but I like command line 
tools because if you store
the command you used to manipulate a file in a certain way, you've 
documented exactly what you
did... whereas writing a description of something you might do in a GUI 
tool is... tricky... and
replicating it /exactly/ on some future occasion is probably impossible.

After making a recording I'd have listened through it very carefully and 
made detailed notes on
performance blemishes, start & stop times of each item, where applause 
starts and ends, how
much silence there is before each item starts and so on.

So for example I could extract a particular piece from an overall 
recording (of maybe the first
half of a concert) taking the audio from, say, 12 mins 17.3 secs in 
through to 14 mins 52.2 secs
(knowing those times from my notes), then apply fade in & fade out over 
the first and last few
seconds of each track... entirely automatically.  If a particular item 
then didn't sound quite
right - maybe a fade is too aggressive or not in quite the right place 
all I do is tweak the
times in a script & rerun the script, and it extracts a slightly 
different part of the original
recording and applies the fades in a slightly different place.]

-- 
Jeremy Nicoll - my opinions are my own