Re: CD ripping

On 1 Apr, in message <2612a3104e.rogerarm@xxxxxxxxxxxxxxxxxxx>
Roger Darlington <rogerarm@xxxxxxxxxx> wrote:

Unfortunately, in classical music, gapless adjacent tracks are the
norm, not exception. Sometimes there are up to a dozen abutted tracks.

This is true in other musical styles as well.

I gather from Wikipaedia, that MP3's cannot be entirely successfuly
played contiguously without artefact by even the best MP3 players.
Whereas lossless compression formats can be, as can WAV and Ogg
Vorbis.

Not quite.

Gaps can appear in MP3 for two main reasons;

- The player is waiting until one track has finished before starting on
the next - this leads to a delay of however long it takes to open,
decode the first frame, and pass the result into the playback buffer.
The delay will vary depending on the filesystem the file is being
fetched from, any other network activity (if it's a network
filesystem), and on how busy the rest of the system is.

This is avoidable in all playback formats, lossy or otherwise, simply
by having the player (or playback module) know what track to play next
before it reaches the end of the current one. It uses an input buffer
of data to be decoded, and an output buffer of decoded audio. As long
as neither buffer empties, playback should be seamless.

On RISC OS, AMPlayer does this.

- Rounding errors - an MP3 contains frames, and each frame encodes a
section of audio of some non-zero duration. There is a minimum length
of a frame, and if the piece of music does not match that exactly,
then the last frame of the MP3 will have to be padded with silence to
make up a complete frame. Unless the player knows that this was done,
and how much was added, it can't tell that this is not intentional.

This latter point introduces a gap in many cases, but there are two ways
around it;

1. Encode the number of silent samples used to pad the last frame
elsewhere in the MP3, and make use of this in the playback module.
This appears to be specific to the LAME encoder, and I'm not aware
that any RISC OS mp3 playback mechanisms make use of it.

2. Rip the CD to a single WAV file (or other non-lossy format), and then
manually specify the track breaks, ensuring that they are always
multiples of the MP3 frame size. This should ensure that no padding
is ever needed to fill out the last frame.

Depending on the type of MP3 being encoded, frames are either 384, 576
or 1152 samples in length. As 1152 is a multiple of 384 and of 576,
ensuring that each WAV, prior to conversion to MP3, is a multiple of
1152 samples in length (approx 26ms for 44100Hz sampling), should result
in an MP3 with zero padding, except for the very last WAV from the CD
(where it doesn't matter as much as there is nothing it seamlessly needs
to flow into).

Alternatively, as others have pointed out, extract to a single WAV, and
encode as a single MP3.

Mike
--
Mike Sandells
Work: mikejs@xxxxxxxxx http://www.liv.ac.uk/csd
Home: mike@xxxxxxxxxx http://www.mikejs.com/
AMPlay 2.00a: http://www.mikejs.com/riscos/amplay.html
.

Loading