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: Really gapless (Read 6169 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Really gapless

In this page of the HA knowledge base...

http://wiki.hydrogenaudio.org/index.php?title=Gapless

It says this...

Quote
Testing for gapless
The best way is by using Test Samples listed at the end of this page.

Some people attempts to detect gapless by generating pure tones, and encoding them into a lossy format. This is not recommended for two reasons:

1. Unless the first tone ends at 0 level and the second tone starts at 0 level, a glitch will be heard during transition.


Surely, exactly the same applies to real tracks from real CDs? Unless they fade to silence (in which case, who really cares about gapless?!) the sample values could be anything.

It seems to me (and someone please explain why I'm wrong) that the enthusiastically embraced encoder/decoder offset/gap correction found in lame and foobar2k closes the gaps, but doesn't deal with the glitches that inevitably ocurr when you make lossy encodes which start or end abruptly. In other words, the pure tone example is a perfectly good way of testing for gapless and glitchless encoding+playback, but the reason the wiki author dislikes it is because it shows up the limitations of the modern lame/foobar2k gapless playback algorithm.

Meanwhile the "depreciated" --nogap switch, when it worked, handled this situation perfectly, albeit by moving the track boundary back slightly. Sadly, this method isn't supported within foobar (but clearly works just be concatenating the files together!), and Gabriel has suggested it should be removed from lame.


If you want to check for yourself, grab glob from here:
http://www.rockbox.org/twiki/bin/view/Main/GaplessHowTo
(end of the page)
and then create a tone, chop it up, number the bits (I've attached a .zip on my own effort), and then do the following...
Code: [Select]
glob -c lame -V 6 --vbr-new -m m --nogap "C:\audio\test 2\*.wav"
copy "C:\audio\test 2\* tone.mp3" /B "C:\audio\all tone.mp3" /B


Listen to all tone.mp3.

Then, as an alternative, try encoding the bits separately, and playing them back2back in foobar2k.

For me, the first one is really glitchless and gapless, while the second one has easily audible glitches in it.

I've attached the tone files I'm using. You can of course play them back2back without glitches as .wavs to prove that they're correct.


What am I doing wrong? Why has no one raised this before?

Cheers,
David.

Really gapless

Reply #1 –
Quote from: 2Bdecided on
What am I doing wrong? Why has no one raised this before?


Didn't Pio raise this some months ago? I remember reading something like this. Let me see if I can find the link.

This is what I was talking about: http://www.hydrogenaudio.org/forums/index....c=18211&hl=

Really gapless

Reply #2 –
Hi David

Wow, you are absolutely right. I have just downloaded the archive and made the test myself and sure enough, there where a little transition artifact between every MP3. So to conclude from your findings, then the enc/dec delay and padding method will only make it so that the transition artifacts will be smaller but not fully gapless.
This is certantly news to me, i must confess.

Thank for the info

CU, Martin.

Really gapless

Reply #4 –
The problem is that lossy encoding involves quantization which alters the signal and that the parts are encoded separately. Lossy transform coders avoid pops (blocking artefacts) in the middle of a track by using overlapped transforms. Obviously there can't be any overlapping at track boundaries since tracks are processed independently. Every transform-based lossy codec is affected but it might be more noticable on some implementations.

There are certain things one could do to improve the situation:
  • A player could extrapolate tracks at both ends to some extend so that it can cross-fade between tracks.
  • <shameless plug> In case of MP3: Encode as one big MP3 and use pcutmp3 to split it into seperate tracks. * </shameless plug>
  • Let encoders "overcode" the start and the end of tracks somehow so the pops are less noticable.
Cheers!
SG

(* Actually, this is my preferred way of encoding for all new CDs)

Really gapless

Reply #5 –
Guess extrapolation is a good idea, it would also probably handle the glitches between tracks that occur when replaygain in single track mode is used.

Really gapless

Reply #6 –
Thank you for the links. I had missed those discussions. I wish I had kept up!

The reason for this post is that the wiki, and several search results, keep saying "lame is gapless from 3.90.3 with fb2k and Rockbox firmware", as if there is no problem left to solve.

Thanks for the explanation SebastianG. You have confirmed what I suspected. When I originally heard that the gapless issue had been solved, I assumed it was a solution with an extra frame in each file, start and end point metadata, and suitable overlapping just like between any other two adjacent frames. When I found out that this apparently gapless solution was produced by encoding separate tracks and just marking start and end points, I realised it could not work consistently, made a test to check this, and here we are!

I'd found pcutmp3 during my searches, and only two things stopped me from using it: the lack of a re-join feature, and the fact that it would make playback even less gapless on bog standard (i.e. gapless unaware) players and portables.

Nevertheless, it's clearly the best solution for now.


I think the wiki/faq/fb2k/lame instructions/help should make it clear that gapless isn't glitchless, and no solution which feeds individual tracks in isolation to a lossy encoder is ever going to be.

The old --nogap switch works quite well, and has the advantage of offering easy splitting/joining, and as small a gap as possible on non gapless players. The disadvantages are not having an accurate start to each track, not playing gapless in foobar2k, and apparently not being reliable.

I have an idea, similar to what you have proposed, that may give the best of both worlds. Do an encode, exactly as --nogap does now, but add two things:

1. an extra frame at the end (the equivalent content to the first frame of the next file, but encoded to stand alone - i.e. no bit reservoir etc)
2. metadata to set the correct start and end point for fb2k and other gapless aware players

Advantages: it would work in fb2k right now (just like mp3s from pcutmp3), and simply stripping any tags (including the lame tag at the start) and the extra frame at the end would give you a standard --nogap file which you could concatenate perfectly, and would play back with as small a gap as possible in gapless unaware players.

A really neat solution would be to find a way to make normal players ignore the lame tag and extra frame (e.g. hide them in an ID3v2 tag?!). That way, even without stripping them, gapless unaware player would play as gapless as they can, but foobar2k could be modified to find them and use them to deliver perfect gapless playback. Then just add a concatenate utility to strip them and merge the mp3s together, and you have everything.


It may be easier to add a re-join feature to pcutmp3 and just live with the larger gaps on gapless unaware players.

Where this is unacceptable, it may be good enough if fb2k can just learn to work properly with –nogap mp3s by default. Will it know what to do if I force tag writing in lame, or will it still hard-cut rather than overlap?

Cheers,
David.

Really gapless

Reply #7 –
Almost a year after, I was wondering if anyone had an EAC / REACT / WACK / ACDIR / pmp3cut method to allow the following with one click from within EAC...

1. AccurateRip checked rip
2. Wavegain album mode parsed to Lame to scale
3. Lame encoded mp3 file (complete album)
4. cut into individual tracks in mp3s
5. file the cuesheet for future use!

Icing on the cake would be some kind of automatic choice of doing the above for albums with cross fades across track boundaries, but doing normal individual track encodes directly for albums where all track boundaries are on silence.

Being able to join the cut mp3s back into a complete album mp3 would be great too.


I did have some of this working, but lost it. The relevant threads are quite old with some dead links, but here they are...

http://www.hydrogenaudio.org/forums/index....0637&st=125
http://www.hydrogenaudio.org/forums/index....showtopic=35654
http://www.hydrogenaudio.org/forums/index....showtopic=45606

If no one has this, I'll work through it all again, and post my results this time so I can come back here in another year to find it again!

Cheers,
David.