Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Help With LAME Options (Read 4917 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Help With LAME Options

I am running Bodhi Linux (Ubuntu) and using RubyRipper to rip my CD collection.  RubyRipper provides a front end to LAME, for encoding to mp3.  My LAME version is 3.9.33. 


Issue #1: Tag Types

Originally, I was passing the following LAME options through RubyRipper:

-V0

The result was mp3 files tagged with both ID3v2.4.0 and ID3v1 tags.  Since I don't want ID3v1 tags, I changed my LAME options to:

-V0 --id3v2-only

Now I no longer got the ID3v1 tags (as expected), but the ID3v2 tags became ID3v2.3.0 instead of ID3v2.4.0 !!

I need help here:

a) What are the advantages of 2.4.0 over 2.3.0?  All my old mp3s have 2.3.0.  Any problem having some files with one type, other files with the other type?

b) Why would the ID3v2 version change due to use of the "--id3v2-only" option?


Issue #2: Track Number Format

Regardless of which version of ID3v2 tag I am writing with LAME 3.93.3, the track number is being written as

<track/[total tracks]>.

For example, 4/10  (Track 4 of 10 tracks.)

With earlier versions of LAME, I always just got the track number (without the total).  That is what I prefer. 

Has the default format for "track" changed in newer LAME versions?  How can I switch it back (if possible)?

I see a LAME option

-tn track[/total]

but I don't know how to use it.

Many thanks for any help on either issue.

Help With LAME Options

Reply #1 –
Quote from: Iggy64 on
a) What are the advantages of 2.4.0 over 2.3.0?  All my old mp3s have 2.3.0.  Any problem having some files with one type, other files with the other type?

I'm not sure that there are any. Id3v2.3 seems to be more universally accepted and is the safer choice, IMO.

Quote
b) Why would the ID3v2 version change due to use of the "--id3v2-only" option?

Not sure about that, unless it's a quirk of that particular version of LAME. Are you sure that it changes?

Quote
Regardless of which version of ID3v2 tag I am writing with LAME 3.93.3, the track number is being written as

<track/[total tracks]>.

For example, 4/10  (Track 4 of 10 tracks.)

With earlier versions of LAME, I always just got the track number (without the total).  That is what I prefer.

That's almost certainly a function of what your ripping program is passing into the encoder for the track field, rather than what LAME does. LAME wouldn't know the total number of tracks. Check the ripper's settings.

Help With LAME Options

Reply #2 –
Thanks for your reply, JJZ.

You noted that ID3v2.3 may be a more-common/safer choice versus v2.4. 
Do you know how LAME chooses which to write?  Is there a LAME option to control that?  (I don't see one.) 
Maybe this is again something that the front-end (in this case, RubyRipper) forces? 
I guess I'll try another front end (like wxLAME) and see what happens.

You asked if I'm sure that the version changes.
Both Mp3diags and MP3tag show that the version changed.
Maybe it was just a coincidence that it changed when I blocked the ID3v1 tag. 
I'll try some other combinations and see if I can figure out what is really triggering the change.
This is all vary curious to me.

I guess you must be right that the front end is guilty for adding the total number of tracks to the track field.
I can't find anything about that in the RubyRipper documentation, but I'll keep digging.
Still, I wonder about the purpose of the LAME option that looks this way in the LAME command-line manual:

--tn track[/total]
    audio/song track number and (optionally) the total number of tracks on the original recording. (track and total each 1 to 255. Providing just the track number creates v1.1 tag, providing a total forces v2.0).

That is, LAME seems to offer the option of "total," but I don't understand what triggers the inclusion of the total.

I'll keep working on this.  I think I'll need a lot more experimenting.

Your help is very much appreciated.

Help With LAME Options

Reply #3 –
I had a copy of LAME 3.99.3 laying around and did a quick encoding of a WAV file using the options you listed. I get an ID3v2.3 tag in both cases.

For the track number, with ID3v2 tags the --tn "some value" will write exactly what is passed to it into the track number field. If I pass "ABC" that's what gets written. Meaning that LAME doesn't care that the value is a number, and it doesn't format it differently. So the issue has to be in what your ripping software is doing.

Help With LAME Options

Reply #4 –
Thanks again -- especially nice of you to run an experiment on my account.  I'm going to try a few more things myself, to get this sorted out.  I'll report back with what I learn.

Thanks for your suggestions.

Since the documentation for RubyRipper doesn't give details on default options being passed, I'm going to run LAME from the command line, as well as with a different front end, to see what happens with the tags.

Help With LAME Options

Reply #5 –
After further review (experimenting):

The current version of RubyRipper apparently writes ID3v2.4 tags plus ID3v1 tags by default, for mp3 encoding.  The tags have zero padding (which is the default for LAME).  RubyRipper does not present the user with any options as to what fields to pass to the tag.  It appears to take whatever information you either type into the track window or import from freedb or wherever, and then pass it to the tag.  The track number always goes with the optional format <track>/<total tracks>.

If I pass any ID3-tag-related options to LAME, then LAME takes over the job of tagging.  For example, if I go into the Preferences > Codecs tab and enter this for mp3 encoding

> V0  --id3v2-only  --pad-id3v2-size 4096

then LAME takes over the writing of the tags.  With the above command, it writes only the ID3v2 tag, and it pads it by the amount I specified (4k).  Also, LAME writes ID3v2.3, instead of the ID3v2.4 that RubyRipper writes by default.  The tag information is automatically passed by RubyRipper to LAME, so I don't have to specify the tag fields (frames) to LAME on the above "command" line.  I was going to try to write a custom subgroup of frames, but I can't find the RubyRipper mapping of frames anywhere.  Again, the track numbers are written <track>/<total tracks>.  No way around this until I somehow figure out the RubyRipper mapping.  It does not seem to be the same as that in EAC.

I can check the padding in the resulting mp3 files using mp3diags, and I find that I get exactly the 4096 bytes I requested.  Now I can add update the tags at a later date with additional information, without having to rewrite the audio files.

With FLAC, things are simpler.  RubyRipper apparently lets FLAC write the Vorbis Comments, and FLAC writes 8k (8192 bytes) of padding by default (and jumps it to 64k for tracks over 20 minutes long).  So there is no need to specify any special tagging parameters for FLAC, unless you want to use LESS padding.

I checked the padding with metaflac, and it is indeed 8k by default.

Bottom line:  There appears to be an advantage to encoding as part of the ripping process.  It enables you to add a padded tag at file creation time, meaning you don't have to rewrite the file when you add the tag.  Less rewrites mean less chances for errors and fragmentation.