Gapless playback with a Linux DLNA server, was: "software to create cue files" Options

[soulsearchingsun]

What I don't understand is: if a single flac file can be played continuously by a DLNA renderer, why can't the software at the PC end be made to organise things such that a series of files looks like a single file when served to the DLNA renderer?

Because usually DLNA software is just a control point. It tells the renderer which file to render by giving a path (the file resides on the server). So DLNA is by default not streaming, but client-server. There are applications that can output a stream via DLNA. Foobar2000 with foo_upnp is able to stream the ouput (AFAIK everything that would be sent to your speakers - not just foobar audio) to a DLNA renderer. This would, obviously, be gapless.
edit: of course, this doesn't help you on linux. But it's possible.

This post has been edited by soulsearchingsun: Apr 12 2012, 14:28

[Richard Kimber]

I may be wrong, but from the little I know about it, Airplay has nothing to do with DLNA: is not a file server system, simply a streaming protocol and as such has not the concept itself of "songs" and gap between them.

Yes, the Airplay functions and normal DLNA music server functions seem to be quite separate on the device itself.

[Nessuno]

Yes, the Airplay functions and normal DLNA music server functions seem to be quite separate on the device itself.

By the way: just made a fast Google search and it seems that there is some AirPlay support on Linux via pulseaudio modules. If it works (can't try myself now as I haven't a Linux box at hand here at home), then you can use one of the many Linux gapless FLAC players and stream his output to the receiver.

[Richard Kimber]

By the way: just made a fast Google search and it seems that there is some AirPlay support on Linux via pulseaudio modules. If it works (can't try myself now as I haven't a Linux box at hand here at home), then you can use one of the many Linux gapless FLAC players and stream his output to the receiver.

Thanks. I don't know anything about Airplay. Does it handle 24bit 192kHz files?

Edit: Actually, I think I found the answer. As I now understand it Airplay is 16 bit and anything else is converted to 16 bit. That's no good to me unfortunately, since I want to deliver high res files to my DAC unsullied by the PC.

This post has been edited by Richard Kimber: Apr 13 2012, 15:28

[greynol]

It's a shame that you seem to be held up by things you cannot hear, unless you are able to demonstrate that you can.

This post has been edited by greynol: Apr 13 2012, 18:41

[Nessuno]

Edit: Actually, I think I found the answer. As I now understand it Airplay is 16 bit and anything else is converted to 16 bit.

Where have you got this information? Don't mistake protocol specifications with capability of single devices that implement it.
And even if, the tradeoff is between gapless and something you very very very very probably cannot hear!

Anyway, best that you can do is to have a try and verify if you hear any difference (and if you feel like reporting back us, please follow the rules greynol pointed you to )

[Richard Kimber]

It's a shame that you seem to be held up by things you cannot hear, unless you are able to demonstrate that you can.

I'm not sure I understand this. I can detect a quality difference between the 16bit/44100 and 24bit/96000 files that I have. It's because I want to find out whether 192k makes any difference that I'm looking for an appropriate way to play the files. Having Airplay downgrade them to 16bit doesn't seems to me like a good way of doing this.

[Richard Kimber]

Edit: Actually, I think I found the answer. As I now understand it Airplay is 16 bit and anything else is converted to 16 bit.

Where have you got this information? Don't mistake protocol specifications with capability of single devices that implement it.
And even if, the tradeoff is between gapless and something you very very very very probably cannot hear!

Anyway, best that you can do is to have a try and verify if you hear any difference (and if you feel like reporting back us, please follow the rules greynol pointed you to )

My source may well not be reliable but FWIW it was a posting here:-
http://www.computeraudiophile.com/content/...s-it-make-sense
I suppose some devices may well exceed the specification. The N-50 manual doesn't give any guidance about its performance in this respect. But I do have a way of testing it, so I could do that in due course.

[Richard Kimber]

It's a shame that you seem to be held up by things you cannot hear, unless you are able to demonstrate that you can.

Actually, I support the aims of the document mentioned, in principle, though in the home environment it's hard to meet the requirements fully. I also think that the reproducibility requirement is formulated too strictly.
"If someone passes the test, others must check if this is possible, by passing the test in their turn." seems to imply that anyone must be able to pass the test, whereas I would only require people who have the same or better hearing abilities to pass the test. Also, some of the links in the FAQ need to be looked at. Linabx doesn't seem to be available, and the links to:
WinABX
FF123's samples For Testing Audio Codecs
ABC/Hidden Reference Audio Comparison Tool
Roberto's public listening tests page
are broken. I haven't checked all of them - maybe it's worth running the page through a linkchecker. I could do that if you wanted.

This post has been edited by Richard Kimber: Apr 14 2012, 14:08

[JimH]

It's a shame that you seem to be held up by things you cannot hear, unless you are able to demonstrate that you can.

Actually, I support the aims of the document mentioned, in principle, though in the home environment it's hard to meet the requirements fully. I also think that the reproducibility requirement is formulated too strictly.

I agree that the standards for what can be said here are sometimes a little too tight. With regard to audio quality, a rational approach is important, but this rationality shouldn't be applied absolutely.

[Nessuno]

As I now understand it Airplay is 16 bit and anything else is converted to 16 bit.

Where have you got this information? Don't mistake protocol specifications with capability of single devices that implement it.

My source may well not be reliable but FWIW it was a posting here:-
http://www.computeraudiophile.com/content/...s-it-make-sense

The only reference to bitdepth and sampling frequency I see there is to the analog output of Airport Express. That, you understand, is different than speaking about AirPlay as a protocol.

The truth is that, AFAIK, as every Apple technology, AirPlay is largely undocumented, so the only reliable result is the one you obtain when you try with your device (and of course it is valid only for that device).

[Richard Kimber]

The only reference to bitdepth and sampling frequency I see there is to the analog output of Airport Express. That, you understand, is different than speaking about AirPlay as a protocol.

Yes. You're right. I didn't really look hard enough. FWIW I've just found an unofficial protocol here http://nto.github.com/AirPlay.html which I'll have a look at. But you're right, I just need to try it on my kit.

[greynol]

I agree that the standards for what can be said here are sometimes a little too tight. With regard to audio quality, a rational approach is important, but this rationality shouldn't be applied absolutely.

The link was given so that the OP could learn about DBT. It was not given as a rule which should be applied absolutely. The one to be applied absolutely is #8 here. Whether you agree with it is not up for debate in this discussion. If you wish to express such a sentiment you can attempt to start a new topic. Further posts about it in this one will be binned. I hope I have made myself clear.

I can detect a quality difference between the 16bit/44100 and 24bit/96000 files that I have.

If you are talking about audible sound quality, you are not allowed to make such a claim unless you also substantiate it with objective evidence per the rule I linked above. Do you have such evidence?

This post has been edited by greynol: Apr 14 2012, 16:49

[Richard Kimber]

I can detect a quality difference between the 16bit/44100 and 24bit/96000 files that I have.

If you are talking about audible sound quality, you are not allowed to make such a claim unless you also substantiate it with objective evidence per the rule I linked above. Do you have such evidence?

It would be helpful for me to read the objective support that others have submitted for their subjective statements about sound quality. Also it would be interesting to hear the test samples. Can you point me to some links?

[db1989]

What does that have to do with it? You made a claim, so you provide evidence for it. How is anyone else relevant? If this is your attempt to dodge a valid challenge to your unsubstantiated and, frankly, very unlikely claim, then it’s a terrible effort. Abide by the rules to which you agreed during registration in your posts, or don’t make them.

[Light-Fire]

It's a shame that you seem to be held up by things you cannot hear, unless you are able to demonstrate that you can.

I'm not sure I understand this. I can detect a quality difference between the 16bit/44100 and 24bit/96000 files that I have. It's because I want to find out whether 192k makes any difference that I'm looking for an appropriate way to play the files. Having Airplay downgrade them to 16bit doesn't seems to me like a good way of doing this.

It is extremely unlikely that you can hear a difference between the 16bit/44100 and 24bit/96000 files. But the proper way to find out is to perform a double blind test because it eliminates the placebo effect from your sound quality evaluations.

If downgrading on the fly from 24/96 to 16/44.1 can help you with the gapless streaming problem you should consider it (because, you can't hear the difference anyways) and you still have your original file preserved at 24/96 (for whatever the reason you want it like that).

[Nessuno]

It is extremely unlikely that you can hear a difference between the 16bit/44100 and 24bit/96000 files. But the proper way to find out is to perform a double blind test because it eliminates the placebo effect from your sound quality

@OP: consider that for such a test to have real value you should use the highest bitrate track and a properly downsampled version YOU make of the same: it is also possible that you actually hear differences between two different downloaded versions of the same track at different sampling rates simply because the seller has tweaked one of them to play different (e.g. louder @24/96) to increase perceived quality.

[greynol]

It's possible that two downloaded versions of the same track originated from different masters. It's also possible that there are conversion problems with the hardware being used to audition the two versions.

However, none of this is relevant unless/until the OP is aware of our rules and our expectation that be followed.

This post has been edited by greynol: Apr 14 2012, 18:19

[Richard Kimber]

What does that have to do with it? You made a claim, so you provide evidence for it. How is anyone else relevant? If this is your attempt to dodge a valid challenge to your unsubstantiated and, frankly, very unlikely claim, then it’s a terrible effort. Abide by the rules to which you agreed during registration in your posts, or don’t make them.

I just want to see what's passed the test.
What's wrong with that? It's all supposed to be public, and publicly verifiable isn't it?

[greynol]

Feel free to search the forum for ABX logs generated by foobar2000 as examples.

http://www.hydrogenaudio.org/forums/index.php?act=Search

[Richard Kimber]

Feel free to search the forum for ABX logs generated by foobar2000 as examples.

http://www.hydrogenaudio.org/forums/index.php?act=Search

Thank you for your help. I tried that, but just got a whole series of general links. Can you point me to just one double blind result that I can look at?

[greynol]

http://www.hydrogenaudio.org/forums/index....lite=%2Bfoo_abx

A whole sub-forum dedicated to the topic:
http://www.hydrogenaudio.org/forums/index.php?showforum=40

This post has been edited by greynol: Apr 14 2012, 21:50

[Roseval]

Gapless
First of all the audio format must support is.
FLAC does and as far as I know MP3 doesn’t
Secondly the media player must support it.
As far as I know, gapless playback is not part of the DLNA standard.

A simple solution to get gapless playback is to rip to single file +cue sheet.
This assumes you’re media player supports cue sheets.
Don’t know if this is the case with DLNA

[db1989]

What does that have to do with it? You made a claim, so you provide evidence for it. How is anyone else relevant? If this is your attempt to dodge a valid challenge to your unsubstantiated and, frankly, very unlikely claim, then it’s a terrible effort. Abide by the rules to which you agreed during registration in your posts, or don’t make them.

I just want to see what's passed the test.
What's wrong with that? It's all supposed to be public, and publicly verifiable isn't it?

I read your post as being more about dodging the obligation that you provide evidence for your specific case. Of course there’s nothing wrong with what you’re saying here, and I hope you find the material interesting. I apologise if I seemed hostile. However, the main point raised by greynol and myself still stands, as well as the recently mentioned possibility that you were comparing apples to oranges.

[julf]

Thank you for your help. I tried that, but just got a whole series of general links. Can you point me to just one double blind result that I can look at?

For one random data point: CA: Julf's Blog - Listening test and Listening Test Results

I guess that limited test was one of the reasons for me getting thrown off CA...