[headwhacker]

Problem is... how can a program tell if a given span of silence is intentional or an artifact of the media mastering or encoding processes?
Short answer: it can't without external assistance. If you don't provide a file with accurate timing information (read: a CUE sheet) or the equivalent then the player has to make calculated guesses.

 
Sometimes we always jump ahead in the middle of a problem and think of complicated ways to solve one. Lets start at the basics shall we.
 
From musichavens post I quote
 
"other artifacts (than timing related) at track boundaries should not be severed either."
 
From this I assume the silence/artifacts in the at least are part of the recording and you want to preserve it.
 
So at bare minimum the implementation should not worry about silence or artifacts at the start or end of the music period. The off/closed option should work this way. The use cue sheet should be an option to those who are willing to use it.
 
 
The source of frustration isn't how bad gapless is implemented. But the lack of option to basically turn it off  completely so you can hear the full length of your recordings.

 

[musicheaven]

   
I take a different view on gapless.  If it doesn't work, the player is usless to me.  Total dealbreaker.  So I would lose plenty of sleep over it.  Had a bought a Colorfly C3 without first reading up on it her on Head-Fi, it would have been in the trash can within minutes, which is exactly where the Oppo player I bought a few years ago went when it refused to play gapless.
 
However, I'm only concerned with FLAC (and I suppose WAV) files.
 
I believe the formats you mention above (mp3, mp4, AAC) are all lossy formats.  Most of them do not have native support for gapless.  I know mp3 did not when it was deveoped.  Some time later, new codecs were released that support gapless mp3s.  To get gapless mp3 playback, the files must be encoded with a specific codec that supports gapless, and then played back with a player (or plugin) that supports that codec.  I didn't pay much attention to it because I very rarely use lossy formats.
 
As I said, I use only FLAC and occasionally WAV files.  If I receive files in another format (like APE or SHN, which I consider long dead formats), I immediately convert them to FLAC.  FLAC has native gapless support (as any format should if it's truly a lossless format).  So there is no reason for any competently designed player to have difficulty playing those files back without adding gaps between tracks.
 
I think what may be going on with the files you bought on iTunes is due to the conversion process.  If you converted those proprietary Apple format files to another file format (like FLAC or mp3), the gaps may have been caused by the software you used to perform the conversion.  You state above that "you don't lose gapless by converting," but what makes you so sure of that?  If you're converting from any file format to mp3, the resulting mp3 files will probably have gaps (unless the encoder specifically supports gapless mp3 encoding).

 I must miss some understanding here but isn't gapless playback the playing of files in a seamless manner so what would the encoding have to do with the playback portion, it is one file playing after another not alone. If I misunderstood then by all means let me know. It is not gap in the file but when they are stitched together. Now see what I said above, the stitching might not be as gap free as one would think however like I said, I have files on the iPhone that I know do not cause any delays when stitched together but does when running on the DX50. Some of those files have not been converted, they are native mp3 files, I know they are lossy but that does not matter for the gapless feature. This is what I used for testing and what I would have assumed would not cause any delays in both environment.

 

[jj69]

Problem is... how can a program tell if a given span of silence is intentional or an artifact of the media mastering or encoding processes?
Short answer: it can't without external assistance. If you don't provide a file with accurate timing information (read: a CUE sheet) or the equivalent then the player has to make calculated guesses.

 
No, there should never, EVER be a need for a cue sheet.  If the silence between tracks is intentional, then the end of the previous track (or the beginning of the current track, I suppose) will contain silence. 
 
In other words, if a studio album with intentinoal gaps of silence between each song is played back on a player that supports gapless, those songs will still have the gaps of silence bewteen the songs when played back, even with the gapless "feature" switched on. 
 
For example, if there is a gap of exactly 2.8 seconds between tracks 1 and 2 on the master recorinding, when played back on a player with gapless switched ON, there should be a gap of exactly 2.8 seconds between them.  If you play the same tracks with gapless switched OFF, the gap will actually be longer - maybe 3.1 seconds.  That extra .3 seconds of silence should not be there.  That doesn't sound like a big deal, but think about how frustrating it would be to listen to a live recording where the audience/crowds noise suddenly drops out for .3 seconds between each song. 
 
 

 

[JoeDoe]

Fellas, do we need to start a "Meditations on Gapless Playback" thread? Everytime I check in to see about the DX50, I keep seeing gapless this gapless that!

 

[jj69]

   I must miss some understanding here but isn't gapless playback the playing of files in a seamless manner so what would the encoding have to do with the playback portion, it is one file playing after another not alone. If I misunderstood then by all means let me know. It is not gap in the file but when they are stitched together. Now see what I said above, the stitching might not be as gap free as one would think however like I said, I have files on the iPhone that I know do not cause any delays when stitched together but does when running on the DX50. Some of those files have not been converted, they are native mp3 files, I know they are lossy but that does not matter for the gapless feature. This is what I used for testing and what I would have assumed would not cause any delays in both environment.

 
I think you may be misunderstanding part of this.  See my post #8674 above and see if that helps. 
 
The problem with the mp3 file format is that it does not support gapless natively.  There are newer mp3 codecs that will support gapless if the file is enoded with that codec AND played back with a player that supports that same codec.  My guess is that your iPhone supports that particular mp3 codec, while the DX50 does not. 

 

[ratinox]

Search back for my "Mind the Gap" post. That explains the two kinds of inter-track silence that can exist in on an album.

Recording professionals and technical folks usually mean the silence that pads the final frame of a file. This is the gap that they want to go away during playback. This is impossible to do computationally because a program can't tell the difference between a string of zeroes that were put there by the recording engineer and a string of zeros put there by the encoder. The only way to get it right all the time is to use some kind of external timing information. This could be in a CUE sheet, or it could be embedded in tags in the file itself. DX50 got support for CUE sheets in v1.2.0. It won't use timing information embedded in tags. This could be the discrepancy that you experience between iThing playback and DX50 playback but I don't know for sure; I've never bought music from Apple and I've never examined their custom tagging.

The rest of us usually mean all silence at the end of a track. Removing this gap -- all silence -- seems to be what DX50's gapless playback option is supposed to do. Again, see my "Mind the Gap" post.

 

[jj69]

  Fellas, do we need to start a "Meditations on Gapless Playback" thread? Everytime I check in to see about the DX50, I keep seeing gapless this gapless that!

 
I know, but it is a very important issue if you listen to anything other than pop music singles. 
 
Admittedly, it frustrates me that so many people do not comprehend the issue.  I'm starting to think it may be generational.  The younger generations did not live through the 1990s when we had CDs, then CD extraction to the computer hard drive, then CD-R burning in the frustrating Track-At-Once mode (which automatically inserted two additional seconds of silence between each track, whether you wanted it to or not), then finally Disc-At-Once mode, which ultimately solved the issue for CD-R burning.  I suppose many young people today have never even owned a CD, much less a vinyl LP, and do not understand the album format in general. 

 

[ratinox]

For example, if there is a gap of exactly 2.8 seconds between tracks 1 and 2 on the master recorinding, when played back on a player with gapless switched ON, there should be a gap of exactly 2.8 seconds between them.  If you play the same tracks with gapless switched OFF, the gap will actually be longer - maybe 3.1 seconds.  That extra .3 seconds of silence should not be there.  That doesn't sound like a big deal, but think about how frustrating it would be to listen to a live recording where the audience/crowds noise suddenly drops out for .3 seconds between each song.

Okay, I'll bite. How is DX50 supposed to be able to distinguish between the 2.8 seconds of silence (zeroes) that you put there and the 0.3 seconds of silence (zeroes) that were created by the encoder to pad out the terminal frame if that information is not provided by some external mechanism?

 

[JoeDoe]

   
I know, but it is a very important issue if you listen to anything other than pop music singles. 
 
Admittedly, it frustrates me that so many people do not comprehend the issue.  I'm starting to think it may be generational.  The younger generations did not live through the 1990s when we had CDs, then CD extraction to the computer hard drive, then CD-R burning in the frustrating Track-At-Once mode (which automatically inserted two additional seconds of silence between each track, whether you wanted it to or not), then finally Disc-At-Once mode, which ultimately solved the issue for CD-R burning.  I suppose many young people today have never even owned a CD, much less a vinyl LP, and do not understand the album format in general. 

I get it. I've got a few books of CDs and a couple dozen vinyl albums. I agree that nailing the "gapless" (misnomer or not) functionality can seriously affect the enjoyment factor of playback. I was just calling attention to the fact that the DX50 (for which this thread is named) has only been mentioned a few times in the last couple pages because of the back-and-forth on gapless playback...
 
Speaking of:
 
Has anyone out there been using their DX50 (without external amp) with a really high impedance IEM like the ER4S or SM64?

 

[musicheaven]

I think you may be misunderstanding part of this.  See my post #8674 above and see if that helps. 

The problem with the mp3 file format is that it does not support gapless natively.  There are newer mp3 codecs that will support gapless if the file is enoded with that codec AND played back with a player that supports that same codec.  My guess is that your iPhone supports that particular mp3 codec, while the DX50 does not. 

Thanks for your above explanation it makes a lot of sense and live recording is a perfect example of gapless playback where the applauding or murmuring public has to be heard consecutively without gaps.

I do have some consecutive live concerts recordings where the two tracks the public is applauding at the end of one track and at the beginning of the other. If I can find those then I know gapless should definitively work or be obvious it does not.

 

[jj69]

Okay, I'll bite. How is DX50 supposed to be able to distinguish between the 2.8 seconds of silence (zeroes) that you put there and the 0.3 seconds of silence (zeroes) that were created by the encoder to pad out the terminal frame if that information is not provided by some external mechanism?

 
What encoder are you referencing?  FLAC does not pad anything with .3 seconds of silence. 

 

[Lilfurbal]

Okay, I'll bite. How is DX50 supposed to be able to distinguish between the 2.8 seconds of silence (zeroes) that you put there and the 0.3 seconds of silence (zeroes) that were created by the encoder to pad out the terminal frame if that information is not provided by some external mechanism?

 
The '2.8' seconds of silence that could deliberately be placed between two tracks reside in the recording itself, dead air as the track is still playing.  The 0.3 seconds is the pause it takes to close out the end of the previous track, and starts playing the next track.   There may also be dead air at the start of the next track, whereas you don't actually hear anything until about 3 seconds in.  However it may have been put together.  The player doesn't know about the 2.8 second gap, it'd only know about the 0.3 second gap it created.  Gapless playback will cause the start of the next song to start exactly when the first track ends (not the audio you can hear, but where the track comes to a close), and this will remove the 0.3 second gap.  Then there will be the original 2.8 seconds of silent playback that was intended. 
 
As I'm trying to say, any silent gaps between songs on a cd aren't put there by the player, or any relevant timing information.  It's still playing the track, just the audio is silent.  It's not the file ending, telling the player 'ok, wait 2.8 seconds.....'now play the next track'. 
 
Also I believe the relevance of cue files is if one decides to rip an entire cd as one singular .flac.  In which case a cue file can be used to skip around tracks.  Playing back the one large .flac will playback the album exactly as it would sound on the cd, without using the .cue file.  However the same can be accomplished with all the tracks split into individual flacs which the .cue file helps to do after the fact, and you play them back in consecutive order with a gapless feature enabled.

 

[ratinox]

What encoder are you referencing?  FLAC does not pad anything with .3 seconds of silence.

FLAC does pad frames and blocks. What it also does is include accurate timing information so that this padding can be trimmed by the player at playback time.

 

[Don Lehrer]

  Fellas, do we need to start a "Meditations on Gapless Playback" thread? Everytime I check in to see about the DX50, I keep seeing gapless this gapless that!

 
You´re right and here I propose you to do so, I think it is an interesting topic but it´s getting way to serious. 
On the other hand, since 1.2.6 my DX is working without freezing, the sound is good (I think I like 1.2.3 more than any)

 

[chiman]