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: lame that understands flac ? (Read 4598 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

lame that understands flac ?

Normally I go flac to mp3 by decoding the flac files and then running lame on the result using --nogap

It would be cool however if I could just lame --flacinput --nogap *.flac

Are there any patches to lame to let it read flac?

I see LameDropXPd v3.02 does it but that looks like a GUI app for Windows.

-=-

And while on the topic of reading flac, this might be asking a bit much, but make use of REPLAYGAIN_* already in the flac instead of needing to re-analyze?

lame that understands flac ?

Reply #1
If you're running Linux (or Mac OS X, if you can bare to install all the required dependencies), caudec can take FLAC files as input and transcode to MP3 using LAME. It doesn't use the --nogap parameter, but I tried a couple of files in deadbeef and while normal MP3s (without the --nogap parameter) are completely gapless, those encoded with --nogap are not (I hear a slight glitch between tracks). I don't know what that parameter is supposed to do. More importantly, it forces you to use a single process for encoding all the tracks (i.e. it's slow).

lame that understands flac ?

Reply #2
There are 32 and 64-bit versions of LAME for Windows on the RareWares site that accept FLAC as input.

http://www.rarewares.org/mp3-lame-bundle.php

I've always rolled my own script to transcode FLAC to MP3, as there are too many notable differences in tagging for the portable players that I use. I drop a number of fields and make sure that others are properly transferred to the desired ID3v2 frame.

What does --nogap do? I've never used it.

lame that understands flac ?

Reply #3
What does --nogap do? I've never used it.


I believe it borrows data from the next sequential track to pad the track it is encoding so it comes out perfect for gapless playback.
It also requires players that support it. I don't know how many do.

lame that understands flac ?

Reply #4
If it actually changed the contents of the files to make the transition between tracks seamless, then players wouldn't need special support for it to work. AFAIK it just writes a tag in the file header that tells the decoder where the extra silence padding starts at the end of the file, which enables the decoder to skip the silence and start the next track if it's designed to respect the unofficial gapless tag.

lame that understands flac ?

Reply #5
Actually, it borrows nothing from the input files. It actually encodes the entire series of input files as a single MP3 stream, chopping at the file transition points to form the individual output files. The result will only play gaplessly in an MP3 player that plays the files in order, and does not reset the decoder between tracks.

As long as you have a modern player, and allow LAME to write Xing/LAME headers to the files, they should decode to the correct length and also play without any perceived gaps.

lame that understands flac ?

Reply #6
Actually, it borrows nothing from the input files. It actually encodes the entire series of input files as a single MP3 stream, chopping at the file transition points to form the individual output files.


How do the reslts differ from just encoding each file individually? Or are we specifically talking about encoding input files that have leading and/or trailing silence, which then gets removed in the process?

lame that understands flac ?

Reply #7
How do the reslts differ from just encoding each file individually? Or are we specifically talking about encoding input files that have leading and/or trailing silence, which then gets removed in the process?


The results differ because every track ends on a full frame boundary near the end time of the track instead of having partial frames at the end time of the track.

By encoding the disc all at once the encoder is able to make these minor adjustments to track lengths (shaving a hair off the end of track 2 and putting it at the start of track 3) in order to do a work around the limitations of MP3.

LAME also does (did) strip the VBR tags from the resulting files when using this option since many of the players which needed this trick also would choke on the extra metadata (--nogaptags forces them to be written).


Quote from: AliceWonder link=msg=0 date=
It also requires players that support it. I don't know how many do.

The whole point of this trick is to not require player support.  It does need a player (as was said above) which doesn't reset the decoder between tracks, but that's a different issue.


Quote from: AliceWonder link=msg=0 date=
It would be cool however if I could just lame --flacinput --nogap *.flac


Be careful with that command line!  Unless your flacs are named with the track number first you'll not encode them in sequence, and defeat the point of the nogap option.

lame --flacinput --nogap  BananasIsTrackOne.flac ApplesIsTrackTwo.flac ...

is the safe way to go if your track names' alphabetical order doesn't match their album order.
Creature of habit.

lame that understands flac ?

Reply #8
Thank you for educating me on gapless mp3.

After some searching of google (which, um, led to posts here) it looks like --nogap is probably best to avoid, and one lame developer even expressed his desire to have it removed in lame 4. Whether it will be or not I suppose is up to them.

What I would like to see in future lame, and unfortunately I do not have the skill to provide it myself is an intelligent --flacinput switch. Any --flacinput would be awesome but intelligent would rock.

What I mean by intelligent --flacinput switch is the ability to read the REPLAYGAIN tags from the vorbis comments and use them when applying replaygain to the mp3 (presumably in the same non-destructive way that mp3gain does). If the information is already in the flac metatags then lame should not need to recalculate it.

I'm not sure how lame currently does replaygain but I believe (and I hope I'm not spouting nonsense) mp3gain altered the actual stream while leaving meta-information on the changes it made. This allowed the sound level alteration to work in all mp3 decoders without them needing to know about replaygain and also allowed the changes to be undone by software that did understand replaygain. If lame could do that during encode from a flac file based upon the meta-information in the flac file, that would be awesome.

I would have it do it by REPLAYGAIN_ALBUM_* if they exist, falling back to REPLAYGAIN_TRACK_* and finally falling back to lame's internal replaygain if the flac doesn't specify. --noreplaygain switch of course would result in ignore the metatags.

I don't think lame should attempt to do anything with any of the other metatags as ID3 is too different.

That I guess is my wish for future lame, if I win it big in the lotto I'll pay a developer to do it, but for now, about all I can afford is a beer

lame that understands flac ?

Reply #9
The replaygain value for a FLAC file will be different from the replaygain value of the resulting MP3 file.  I've never studied how much, but they will differ.
Creature of habit.