Here's my own personal prejudices, and it reflects
the kind of organizations I work for - large, lots
of edits/editing stations, lots of moving files around
(internationally, desktop-to-desktop, studio-to-studio,
into broadcast chains, etc). Total audio storage is half
a terabyte at 6:1 compression - a heap o' hours.
While I am sympathetic to the "Unix does individual tasks well",
when I'm in mail and want to view an Excel file, I don't want
to have to manually launch a new application to view it - if
another application opens by me double-clicking, I'm happy.
(yes, I use vi instead of e-macs as well, but only because
I never memorized a million ctl-alt-whatever options from
e-macs. Ideally a full music package would be more intuitive,
though having some command-line controls for automation or
fast batch/manual modes.)
Similarly with audio and MPEG - while some tasks can be separated
out, more and more I'm seeing overlapping functions, so need
applications to work well together. I've been using Python as
the glue for that for some time, but I'm aiming my sights further
at this point - a hybrid QT/C++/Python "total solution" seems
my preference, though I'm not terrible dogmatic about languages.
1) MPEG editing. MP2 is known for taking more generations of
editing without degradation and being more appropriate for multi-track
editing. MP3 is better for low bit-rates but is computationally more
expensive. I need both to work together, as MP2 is more common
in the broadcast arena and most editors (with WAV), while all of our
Web,
internet transfers & ISDN are MP3. MP3 "editing" might be a matter of
splicing
frames together (maybe zeroing out junctions to remove pops, or figuring
out a way to do cross-fades as well). Bitrates of 16kbps to 256kbps are
used. Automatic format conversions is preferable, but this can be
difficult when equipment/software from different vendors is used.
AAC remains an unknown element for the moment.
2) Scheduling/playlists. While doing personal playlists for Web radio
is relatively straightforward, providing multiple play streams made
up of tracks of different formats (WAV, MP2, MP3), getting the
time-lengths
right, allowing in-program cuts to fit, allowing more than one user to
put
together lists with appropriate security, are all considerations.
3) CDDB - we have lots of music, and want an on-line music database
that's easy for users to access and use as background or fill music.
MP3 format seems reasonable, archiving CD's much faster than real-time
is preferred, and inserting track ID3 information into a database is
useful, especially if augmented by a music librarian's further comments
or a journalist's transcript.
4) Portable devices - we use a lot of minidiscs, but have no way
to grab raw data off the discs (ATRAC decompression, file formats,
etc.) Don't know of any MP3 portable recorders, though there are rumors
that some are being worked on. As Linux gets ported to handheld devices
with faster and faster processor speeds, is this a realistic option
with something like LAME to do portable real-time recording?
What bitrates/sound-qualities are sustainable? What hardware would
be required?
While this may be outside of the LAME project, it's good to keep in
mind what applications this may be used for. I really like being able
to import and export files of different formats - whether this is
handled by Sox with an easy tie-in, or a new LAME tool is irrelevant,
but shouldn't be separated in a final application. However, this
has little to do with perfecting LAME's encoding operations with
regards to a pyschoacoustical model. Knowing what bit-rates you're
after is important (BladeEnc ignores rates below 96 kbps, which makes
it useless for most Web-based applications).
One thought I've had is actually keeping a database of all frame
start locations for each MP3 file (and to use a frame scanner
for new additions) as well as some other bitrate/sample rate
info. While this may seem like a lot of overhead, it's not
that much work for something like MySQL on a Pentium, and it
makes splicing tracks a whole lot easier. Even if the database
gets corrupt, a re-scan isn't too terribly time-consuming, though
for 500 Gigabytes is not insignificant.
More later,
Bill
[EMAIL PROTECTED] wrote:
>
> Hi all,
>
> just wanted to spark a bit of thought on some of the future direction
> of lame. This occured to me after I read that for the update to lame3.30 we
> can now do ID3 tags
>
> Consider the following ideas related to mp3 encoding
> - CD-ripping (CD paranoia)
> - resampling (sox)
> - ID3 tags
> - CDDB lookups
> - mp3 databases
>
> Should these features be part of LAME? Or should these be considered "support
> materials" and use some other program (like GRIP) to combine all these
> functions?
>
> I remember somebody saying about unix programs that each program only does one
> thing, but does it well.
>
> I'm not advocating or dissenting from features being included in LAME, i just
> wondered what other people think.
>
> later
> mike
> --
> MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
--
Bill Eldridge
Radio Free Asia
[EMAIL PROTECTED]
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
