HydrogenAudio

Lossy Audio Compression => MP3 => MP3 - General => Topic started by: TakuSkan on 2003-12-03 19:42:17

Title: LAME --nogap in EAC
Post by: TakuSkan on 2003-12-03 19:42:17
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
Title: LAME --nogap in EAC
Post by: witt on 2003-12-03 20:16:38
You can get gapless playback without --nogap option.
I think --nogap is totally useless.

This topic is very helpful. (http://www.hydrogenaudio.org/forums/index.php?showtopic=15177&view=findpost&p=152898)
Title: LAME --nogap in EAC
Post by: Peter on 2003-12-03 20:21:05
--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).
Title: LAME --nogap in EAC
Post by: TakuSkan on 2003-12-03 22:41:17
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
Title: LAME --nogap in EAC
Post by: TakuSkan on 2003-12-04 01:27:33
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. (http://www.hydrogenaudio.org/forums/index.php?showtopic=15177&view=findpost&p=152898)

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
Title: LAME --nogap in EAC
Post by: Peter on 2003-12-04 02:01:49
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. (http://www.hydrogenaudio.org/forums/index.php?showtopic=15177&view=findpost&p=152898)

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.
Title: LAME --nogap in EAC
Post by: saratoga on 2003-12-04 04:08:59
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.
Title: LAME --nogap in EAC
Post by: TakuSkan on 2003-12-04 07:38:41
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
Title: LAME --nogap in EAC
Post by: pdh11 on 2003-12-04 12:18:12
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
Title: LAME --nogap in EAC
Post by: pdh11 on 2003-12-04 12:26:38
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
Title: LAME --nogap in EAC
Post by: Peter on 2003-12-04 12:28:08
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).
Title: LAME --nogap in EAC
Post by: saratoga on 2003-12-04 18:42:43
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).
Title: LAME --nogap in EAC
Post by: TakuSkan on 2003-12-04 19:27:56
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 (http://classic.winamp.com/plugins/detail.jhtml?componentId=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
Title: LAME --nogap in EAC
Post by: Moneo on 2003-12-04 22:07:43
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.
Title: LAME --nogap in EAC
Post by: TakuSkan on 2003-12-05 20:29:34
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
Title: LAME --nogap in EAC
Post by: TakuSkan on 2003-12-05 20:50:41
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
Title: LAME --nogap in EAC
Post by: Thrasher on 2004-01-11 13:49:58
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. (http://www.hydrogenaudio.org/forums/index.php?showtopic=15177&view=findpost&p=152898)

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.
Title: LAME --nogap in EAC
Post by: criZZb on 2004-01-12 19:34:32
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...
Title: LAME --nogap in EAC
Post by: PhileasFogg on 2004-05-17 04:54:34
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?
Title: LAME --nogap in EAC
Post by: Peter on 2004-05-17 11:20:27
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).
Title: LAME --nogap in EAC
Post by: Gabriel on 2004-05-17 11:53:08
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).
Title: LAME --nogap in EAC
Post by: PhileasFogg on 2004-05-17 18:08:11
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...