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 --nogap in EAC (Read 17266 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

LAME --nogap in EAC

I've been reading through posts on the LAME --nogap option.  Some say the MP3 format doesn't allow gapless files.  Some people say they've gotten it to work. 

I'm gathering that it >can< work, but won't totally eliminate the gap.

I tried configuring EAC with the command: "--alt-preset standard --nogap  %s %d" but didn't have any success.  EncSpot has a field that indicates a --nogap encoded MP3, but none of the MP3s I encoded indicated that --nogap had been applied.

Can anyone tell me if it's possible to get EAC to execute --nogap on a series of tracks?

Thanks,

Shel
Geopoliticus Child Watching the Birth of the New Man


LAME --nogap in EAC

Reply #2
--nogap switch itself needs player-side support to do its job (decoder must not be reinitialized between files), and not many software players can possibly do that (supposedly some hardware players play decode --nogap files gaplessly).
Microsoft Windows: We can't script here, this is bat country.

LAME --nogap in EAC

Reply #3
Quote
--nogap switch itself needs player-side support to do its job ...


But using EncSpot to analyze the MP3s I encoded with EAC, it's showing that the LAME option --nogap wasn't configured for some reason.  Maybe my command line options aren't set  right.  I'd like to 1st see that happen... and then check things down the line.

Shel
Geopoliticus Child Watching the Birth of the New Man

LAME --nogap in EAC

Reply #4
Quote
--nogap switch itself needs player-side support to do its job (decoder must not be reinitialized between files), and not many software players can possibly do that (supposedly some hardware players play decode --nogap files gaplessly).


Witt pointed me to your post on --nogap here: This topic is very helpful.

A few messages below that you posted a couple of sample gapless MP3s to test.  Looking at them with EncSpot, it seems the fields for nogap show the same 'no' results as all of my LAME encoded MP3s, with or without having set --nogap on the commend line.  So I guess EncSpot is not reporting whatever you set for nogap when you created those files.

I see your command line was basic, instead of the -Y switch which I can't find any documenation for: --alt-preset standard -Y

Are you saying that by rote, LAME versions v3.90.3 and above encode MP3s as gaplessly without setting any switches on the command line?  Or am I still missing something?

Shel
Geopoliticus Child Watching the Birth of the New Man

LAME --nogap in EAC

Reply #5
Quote
Quote
--nogap switch itself needs player-side support to do its job (decoder must not be reinitialized between files), and not many software players can possibly do that (supposedly some hardware players play decode --nogap files gaplessly).


Witt pointed me to your post on --nogap here: This topic is very helpful.

A few messages below that you posted a couple of sample gapless MP3s to test.  Looking at them with EncSpot, it seems the fields for nogap show the same 'no' results as all of my LAME encoded MP3s, with or without having set --nogap on the commend line.  So I guess EncSpot is not reporting whatever you set for nogap when you created those files.

I see your command line was basic, instead of the -Y switch which I can't find any documenation for: --alt-preset standard -Y

Are you saying that by rote, LAME versions v3.90.3 and above encode MP3s as gaplessly without setting any switches on the command line?  Or am I still missing something?

Shel

--nogap is useless, deprecated, and hardly supported anywhere.
All recent versions of LAME (3.90 and above if I remember correctly) always write additional gapless playback info (amounts of samples to skip) into LAME tag (unless you disable LAME tag writing). All you need is a player that reads and utilizes info from LAME tag; see the topic linked above for more info.
And again, gapless playback using LAME tags has absolutely nothing to do with --nogap switch.
Microsoft Windows: We can't script here, this is bat country.

LAME --nogap in EAC

Reply #6
Quote
I've been reading through posts on the LAME --nogap option.  Some say the MP3 format doesn't allow gapless files.  Some people say they've gotten it to work. 

I'm gathering that it >can< work, but won't totally eliminate the gap.

I tried configuring EAC with the command: "--alt-preset standard --nogap  %s %d" but didn't have any success.  EncSpot has a field that indicates a --nogap encoded MP3, but none of the MP3s I encoded indicated that --nogap had been applied.

Can anyone tell me if it's possible to get EAC to execute --nogap on a series of tracks?

Thanks,

Shel

LAME is gapless for me.  Just use foobar to play or record CDs and it should work automaggically thanks to peter's efforts.

LAME --nogap in EAC

Reply #7
Quote
--nogap is useless, deprecated, and hardly supported anywhere.
All recent versions of LAME (3.90 and above if I remember correctly) always write additional gapless playback info (amounts of samples to skip) into LAME tag (unless you disable LAME tag writing). All you need is a player that reads and utilizes info from LAME tag;


I've learned this must be the case in a few hours of setting up FooBar2000 and WinAmp 2.91 with CrudSoft gapless plugin, and then playing some of the pertinent LAME 3.92 encoded MP3s I've ripped in the past few months.  Once I got a software gapless MP3 player set up, I finally have things working.

Quote
And again, gapless playback using LAME tags has absolutely nothing to do with --nogap switch.


Okay... I'm finally grokking what you and others have written, and this explains why the gapless fields in EncSpot don't mean much.

I was hoping to report my success at running FooBar2000 on a couple underpowered <200MHz CPU notebooks.  But even after disabling DSP components, and setting a more efficent waveOut device, it still requires more resources than WinAmp.  WinAmp must have introduced v2.91 in the past year or so.  I downloaded 2.81 to use on these old notebooks a year or more back, and don't recall there being a 2.91 at that point.  Could have missed it though.

Shel
Geopoliticus Child Watching the Birth of the New Man

LAME --nogap in EAC

Reply #8
Quote
I tried configuring EAC with the command: "--alt-preset standard --nogap  %s %d" but didn't have any success.  EncSpot has a field that indicates a --nogap encoded MP3, but none of the MP3s I encoded indicated that --nogap had been applied.

That's not going to work, because for no-gap, Lame needs to be told about all the gapless files on the same command-line: "lame --nogap 1.wav 2.wav 3.wav..."

Quote
Can anyone tell me if it's possible to get EAC to execute --nogap on a series of tracks?

I've never found a way. I think you have to do it manually (or in a separate script, or whatever).

Peter

LAME --nogap in EAC

Reply #9
Quote
But using EncSpot to analyze the MP3s I encoded with EAC, it's showing that the LAME option --nogap wasn't configured for some reason.

When you encode a set of WAVs in a single Lame invocation with --nogap, all but the last get the informational bit set. (The last file in the group doesn't get the bit, because nothing special happened at the end of it.) With EAC, there's no way to encode more than one WAV per invocation of Lame, so --nogap never does anything, and the informational bit is never set.

Peter

LAME --nogap in EAC

Reply #10
Quote
Quote

--nogap is useless, deprecated, and hardly supported anywhere.
All recent versions of LAME (3.90 and above if I remember correctly) always write additional gapless playback info (amounts of samples to skip) into LAME tag (unless you disable LAME tag writing). All you need is a player that reads and utilizes info from LAME tag;


I've learned this must be the case in a few hours of setting up FooBar2000 and WinAmp 2.91 with CrudSoft gapless plugin, and then playing some of the pertinent LAME 3.92 encoded MP3s I've ripped in the past few months.  Once I got a software gapless MP3 player set up, I finally have things working.

Quote
And again, gapless playback using LAME tags has absolutely nothing to do with --nogap switch.


Okay... I'm finally grokking what you and others have written, and this explains why the gapless fields in EncSpot don't mean much.

I was hoping to report my success at running FooBar2000 on a couple underpowered <200MHz CPU notebooks.  But even after disabling DSP components, and setting a more efficent waveOut device, it still requires more resources than WinAmp.  WinAmp must have introduced v2.91 in the past year or so.  I downloaded 2.81 to use on these old notebooks a year or more back, and don't recall there being a 2.91 at that point.  Could have missed it though.

Shel

Foobar2000 heavily relies on floating-point math, it will be slower than Winamp on older machines (while it actually decodes MP3 faster than Winamp on athlon-class CPUs).
I suggest that you actually read the topic linked above, you seem to have missed major part of it (especially my post explaining what exactly gapless playback is, and links to in_mpg123).
Microsoft Windows: We can't script here, this is bat country.

LAME --nogap in EAC

Reply #11
Quote
Quote

--nogap is useless, deprecated, and hardly supported anywhere.
All recent versions of LAME (3.90 and above if I remember correctly) always write additional gapless playback info (amounts of samples to skip) into LAME tag (unless you disable LAME tag writing). All you need is a player that reads and utilizes info from LAME tag;


I've learned this must be the case in a few hours of setting up FooBar2000 and WinAmp 2.91 with CrudSoft gapless plugin, and then playing some of the pertinent LAME 3.92 encoded MP3s I've ripped in the past few months.  Once I got a software gapless MP3 player set up, I finally have things working.

Quote
And again, gapless playback using LAME tags has absolutely nothing to do with --nogap switch.


Okay... I'm finally grokking what you and others have written, and this explains why the gapless fields in EncSpot don't mean much.

I was hoping to report my success at running FooBar2000 on a couple underpowered <200MHz CPU notebooks.  But even after disabling DSP components, and setting a more efficent waveOut device, it still requires more resources than WinAmp.  WinAmp must have introduced v2.91 in the past year or so.  I downloaded 2.81 to use on these old notebooks a year or more back, and don't recall there being a 2.91 at that point.  Could have missed it though.

Shel

Try turning off dither/noise shaping as well.  Its pretty CPU intensive (relatively speaking).

LAME --nogap in EAC

Reply #12
Quote
Foobar2000 heavily relies on floating-point math, it will be slower than Winamp on older machines (while it actually decodes MP3 faster than Winamp on athlon-class CPUs).

Okay...  I've been using my two tiny Toshiba Libretto's, a 70CT and a 100CT as multi-purpose MP3 player/Notebooks w/20GB & 40GB HDDs for MP3 storage...  and actually, FooBar2000 does in fact run relatively well on the 166MHz 100CT.  There's a little lag time after scanning the playback position forwards or backwards, but for 99% of use, MP3s play relatively gaplessly from one to the next.

Quote
I suggest that you actually read the topic linked above, you seem to have missed major part of it (especially my post explaining what exactly gapless playback is, ...

Okay... I've re-read your posts again.  Though I have to confess that I'm not that familiar with MP3 coding, so a lot of this is a bit of a stretch for me.

You address the problems as being rooted in "Gapless decoding", and "Gapless output".

Gapless decoding problems being:

1) problems, "truncating last samples or adding extra null samples"
2) "encoder/decoder delay" necessitating storing,  "two additional numbers",

Gapless output problem being:

1) "old) players have a design flaw requiring them to reopen wave output device between tracks"

Okay, it's nice to have a handle on the 'whys' of what causes the problem, but again I confess I'm just trying to figure out how to address the issue.  Were you indicating that I might not be able to achieve effective gapless playback with my <200MHz systems?  I know I'm probably never going to achieve flawless nogap playback, but WinAmp 2.91 with the CrudSoft gapless plugin seems to do a commendable job of coming close.

Quote
and links to in_mpg123).

My apologies...  I did try to track down more info on in_mpg123.  But the links provided all pointed to Japanese language websites where I had a hard time gleaning much useful information.  Have you compared in_mpg123 to the CrudSoft plugin?:

http://classic.winamp.com/plugins/detail.j...mponentId=24303

In another post, you stated:

Quote
Proper gapless playback in Winamp requires both in_mpg123 and "gapless" output plugin (configured not to reopen output between tracks, but without removing silent samples, since input plugin already does that without guessing exact number of samples to remove).

Can you point me to URLs where I can download both in_mpg123 and whatever '"gapless" output plugin' I may need to get WinAmp fine tuned?  Are the settings in in_mpg123 written with Japanese characters?

Thanks for your feedback.

Shel
Geopoliticus Child Watching the Birth of the New Man

 

LAME --nogap in EAC

Reply #13
Quote
Were you indicating that I might not be able to achieve effective gapless playback with my <200MHz systems?

Maybe yes, maybe no.

For starters, try turning off dithering as suggested by Mike Giacomelli.

Also, increase buffer size and increase playback thread priority.

A P166 should be able to handle foobar2000's mp3 decoder at a reasonable speed.

LAME --nogap in EAC

Reply #14
Quote
Try turning off dither/noise shaping as well.  Its pretty CPU intensive (relatively speaking).

Sorry I missed your post Mike.  In FB2K v0.7 that I've set up, dithering/noise shaping comes disabled out of the box.  I had tried configuring a size for 'Full file buffering' on that playback options window too, and it had no affect.  Playback thread priority was also set at 'max', and reducing it only made the playback audio stutter.

Shel
Geopoliticus Child Watching the Birth of the New Man

LAME --nogap in EAC

Reply #15
Quote
For starters, try turning off dithering as suggested by Mike Giacomelli.

Okay... as I told Mike, that was already disabled by default.

Quote
Also, increase buffer size and increase playback thread priority.

Thread priority was already set at 'max'.  I wasn't sure what to set the buffer size to.  So I just guessed at these sizes, and none had any affect: 50K, 100K 200K 400K, 800K, 1000K, 2000K, 5000K.

Quote
A P166 should be able to handle foobar2000's mp3 decoder at a reasonable speed.

In fact, I was able to get my >120MHz< Libby to play gapless MP3s by making a couple tweaks.  I checked the ASPI drivers with Adaptec's Win98 utility, and found a mismatch between the two configured files.  Between correcting that, and updating the sound drivers for the (noisy... Layla in my sights) Yamaha OPL3-SAx chip, the little hiccup I was getting between files disappeared.

I did the same to the 166MHz Libretto hoping I could get the equalizer working without MP3s stuttering.  The time between the stutters was increased, but I've still not been able to tweak anything on that Lib to get equalizaion working right.  That's the only DSP component I'd >really< like to have working.

Shel
Geopoliticus Child Watching the Birth of the New Man

LAME --nogap in EAC

Reply #16
Quote
Quote
Quote
--nogap switch itself needs player-side support to do its job (decoder must not be reinitialized between files), and not many software players can possibly do that (supposedly some hardware players play decode --nogap files gaplessly).


Witt pointed me to your post on --nogap here: This topic is very helpful.

A few messages below that you posted a couple of sample gapless MP3s to test.  Looking at them with EncSpot, it seems the fields for nogap show the same 'no' results as all of my LAME encoded MP3s, with or without having set --nogap on the commend line.  So I guess EncSpot is not reporting whatever you set for nogap when you created those files.

I see your command line was basic, instead of the -Y switch which I can't find any documenation for: --alt-preset standard -Y

Are you saying that by rote, LAME versions v3.90.3 and above encode MP3s as gaplessly without setting any switches on the command line?  Or am I still missing something?

Shel

--nogap is useless, deprecated, and hardly supported anywhere.
All recent versions of LAME (3.90 and above if I remember correctly) always write additional gapless playback info (amounts of samples to skip) into LAME tag (unless you disable LAME tag writing). All you need is a player that reads and utilizes info from LAME tag; see the topic linked above for more info.
And again, gapless playback using LAME tags has absolutely nothing to do with --nogap switch.

You say that the --nogap switch is useless, but I found --nogap encoded track to have shorter gaps when played back in Winamp with standard output settings.

LAME --nogap in EAC

Reply #17
Quote
You say that the --nogap switch is useless, but I found --nogap encoded track to have shorter gaps when played back in Winamp with standard output settings.

You say that shorter gap resolves your problem?

--nogap encoded files will not play perfectly gapless on players supporting reading encoder delay and padding info, because they (AFAIK) add some samples from previous file, which isn't really a good thing, don't you think?

edit:
AFAIK added --- just to be... hmmm...
criZZb

LAME --nogap in EAC

Reply #18
why wouldn't --nogap files play just as well on "players supporting reading encoder delay and padding info" ??? 

the redistribution of samples couldn't be a problem, since we're talking about a continuous stream of music here--but i could see it being a problem if the --nogap files don't have the same special header info that a regular lame file has--is this the case?

LAME --nogap in EAC

Reply #19
Quote
why wouldn't --nogap files play just as well on "players supporting reading encoder delay and padding info" ??? 

the redistribution of samples couldn't be a problem, since we're talking about a continuous stream of music here--but i could see it being a problem if the --nogap files don't have the same special header info that a regular lame file has--is this the case?

Difficult to read the topic before replying to it, isn't it ?
Quote
--nogap switch itself needs player-side support to do its job (decoder must not be reinitialized between files), and not many software players can possibly do that (supposedly some hardware players play decode --nogap files gaplessly).
Microsoft Windows: We can't script here, this is bat country.

LAME --nogap in EAC

Reply #20
Anyway I am in favor of removal of --nogap in v4.
IMO using the delay values from the tag is way more elegant, and at least it does not reduce quality of individual tracks (unlike --nogap).

LAME --nogap in EAC

Reply #21
sorry, zZzZzZz, i wasn't clear about what i meant:  I didn't mean that --nogap files would generally play gaplessly..  but i am very confused about one thing (and yes, i have searched through the forums)--you say that --nogap will only work if the player doesn't reinitilaize the decoder between files, but that otherwise it works.

however, isn't that also necessay for regular --present standard mp3s to play back gaplessly?? in other words, wouldn't reinitializing the decoder introduce a gap no matter what kind of mp3 you're dealing with?  and wouldn't that therefore mean that players which playback --preset standard files gaplessly don't reinitialize the decoder, and therefore would also play back --nogap files gaplessly?

forgive me if i sound like i'm trying to argue with you--i'm just explaining how i understand it at the moment, so some can tell me if i've got it wrong.. i'm not 'claiming' anything...