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
_______________________________________________
get_iplayer mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/get_iplayer
