Universalmediaserver: Transkoding audio files to LPCM gives wrong pitch (FFmpeg Audio) for some files

[Nadahar]

Some audio files, when transcoded with FFmpeg Audio, plays with wrong pitch when I play them om both my available renderers (Onkyo TX-NR807 and foobar2000). There aren't many options for audio transcoding, toggeling resampling to 44,1/48 doesn't fix it. It's certain files, and they are always transcoded with wrong pitch (some to low, some to high). When I try to transcode the same file with the same options (only -f wav instead of -f sb16be and a filename instead of pipe), the files play normally in all the media players I've tested.

I've looked at bitrate, sampling rate, bit depth on the source files without being any smarter (it probably takes more). Do anyone have any knowledge of this, is it some kind of a bug, a DNLA/uPnP limitation or some configuring options I haven't found?

Examples:

• Format: OGG, Codec: Vorbis, VBR, 44.1 KHz (pitch too high)
• Format: M4A, Codec: AAC LC, VBR, 44.1 KHz (pitch too high)
• Format: M4A, Codec: AAC LC, VBR, 8 KHz, Mono (pitch smurf high)
• Format: 3GP, Codec: HE-AACv2, VBR, 32 KHz (pitch too high)
• Format: M4A, Codec: AAC LC, VBR, 22.05 KHz (pitch too high)
• Format: M4A, Codec: AAC LC, VBR, 44.1 KHz (pitch too high)
• Format: M4A, Codec: ALAC, VBR, 44.1 KHz, 16 bits (pitch too high)
• Format: AC3, Codec: AC3, CBR: 448 Kbps, 48 KHz, 16 bits, 5 channels (pitch too low)
• Format: WAV, Codec: DTS, CBR: 1411.2 Kbps, 44.1 KHz, 24 bits, 5 channels (pitch too low)
• Format: FLAC, Codec: FLAC, VBR, 44.1 KHz, 16 bits (pitch too high)

[Nadahar]

I've found the problem. The problem only occurs when transcoding to LPCM. When transcoding to WAV or MP3 the samlpe rate is not specified probably because it's in the headers, but since LPCM is a raw stream there's no headers and it has to be specified. The specification of the sample rate is flawed and only "luck" will make it correct some times:

RendererConfiguration line 1288:

                    // Default audio transcoding mime type
                    matchedMimeType = HTTPResource.AUDIO_LPCM_TYPEMIME;

                    if (isTranscodeAudioTo441()) {
                        matchedMimeType += ";rate=44100;channels=2";
                    } else {
                        matchedMimeType += ";rate=48000;channels=2";
                    }

This also has to do with it, although it seems to be "by design":
FFMpegAudio line 212:

        if (configuration.isAudioResample()) {
            if (params.mediaRenderer.isTranscodeAudioTo441()) {
                cmdList.add("-ar");
                cmdList.add("44100");
            } else {
                cmdList.add("-ar");
                cmdList.add("48000");
            }
        }

The logic seems to be for me that one have to enable "Automatic Resampling to 44,1 or or 48 KHz" under Transcoding -> FFmpeg Audio to make isAudioResample() true. If that option is enabled, and only then, the renderer configuration option TranscodeAudioTo441kHz seems to come into play and decide if transcoding is forced to 44100 or 48000.

The logic behind this is hard for me to grasp, and expecting anyone not knowing UMS "to the teeth" to figure out how to configure it is unrealistic. Even if you understand the configuration logic, it's impossible to get transcoding to work properly as it depends on your source files having the right sample rate.

[atamariya]

@Nadahar did LPCM work for you? My denon receiver couldn't play the stream from UMS. So I settled down on MP3.

[Nadahar]

@atamariya LPCM works on my Onkyo, but there are pitch problems on many files. I've made a fix #729 that fixed some cases, but there are still files playing with wrong pitch. I think it's due to UMS violating DLNA profiles (sending profiles that's not valid) / lacking sample frequency and channels information combines with the fact that LPCM is a pure binary format without any header to help rectify the missing information.

Even though there's been some times since I looked at this, as I remember it the problem is with "non standard" sample frequencies and channels. 48 KHz stereo plays fine (or 44,1 - don't remember).

[Nadahar]

Thanks to @Sami32's endurance in searching through DLNA documents, it seems that the only valid values for LPCM is:

audio/L16;channels=1;rate=44100
audio/L16;channels=2;rate=44100
audio/L16;channels=1;rate=48000
audio/L16;channels=2;rate=48000

That means that #729 probably fixed it for valid files, files with other properties need to be transcoded to play correctly. I'm still not sure what would be a proper way to handle this with the traditional renderer configuration system, as it hightly unlikely that all renderers can play all 4 combinations.

[ExSport]

Maybe I didn't read whole discussion carefully but I remember that in past I tested 5.1 and 7.1 LPCM on parents Pioneer receiver and I saw 5.1 and 7.1 was detected on it. I tested it due to the reported bug that some audio channels were switched and if I remember right MEncoder also generated correct 5.1 LPCM but not 7.1 due to some limitation or bug.
Anyway I was able to play more than 2.0 LPCM.

[Nadahar]

@ExSport Thanks, now I'm completely confused.

[ExSport]

@Nadahar I found some older discussion about working multichannel LPCM:
http://www.ps3mediaserver.org/forum/viewtopic.php?f=6&t=4961
I tested it on PS3 and external receiver in past and got 5.1 LPCM from DTS Core. I also got 7.1 on receiver when used TrueHD which had 7.1 support in MEncoder but there were some other bugs like silent channels or wrong mapping (can't find post in forum when I described it)
Little bit OT:
When I searched for link above I found also the discussion from founder of PMS Shagrath about audio-passthrough:
http://www.universalmediaserver.com/forum/viewtopic.php?f=14&t=1303&start=10#p7803
Maybe for someone interesting so linking it there.
@Sami32 somewhere else posted some newer info from Microsoft and other SW from what I understood that bandwidth limitation mentioned by shagrath can be overcome by using more streams to not violate IEC60958/IEC61937 with its 1.5Mbit/s max.
Maybe I wrote bullshit as I didn't read it carefully but not not loose this maybe useful info I added it there so also @atamariya @SubJunk @valib @SharkHunter or @skeptical can find it useful, maybe :)

[ExSport]

Btw. from discussion in other issues where is @Sami32 active, I have to say that I tested it on PS3 only.
It means when PS3 detects LPCM, it redirects it automatically to external receiver so sending LPCM2.0 in MIME type or elsewhere is ignored by Renderer and external receiver doesn't need this info for correctly detect nr. of channels. Maybe because of that other renderers play sound slowly/incorrectly as they need info about nr. of channels and when you will send LPCM 2.0 mime type but it is in reality 5.1 bitstream, it is produced incorrectly. PS3 is specific here so take my info with reserve as it seems you are solving different problem, when renderer directly reproduces audio and not external receiver.

[Sami32]

@ExSport Channel and bitrate in content-type are mandatory fields in the DLNA standard, that need to be send with L-PCM stream; the Linear PCM (2 channels) transcoding part was done by Tomeko in 2011 in the PMS era.
PS3, like many crappy gamers renderers :wink: , are not know to be very DLNA standard respectuous.
That said, playing non DLNA standard LPCM streams have many chance to give problems.

As already discussed with @Nadahar , 1.5 Mbit/s maximum is not coming from IEC 60958 or any other norme, standard; it's not limitation anymore. We have 6.144 Mbit/s DVD specifications limit for now, that will change when we'll not use DVD anymore (https://en.wikipedia.org/wiki/DVD-Video)
So i guess that the S/PDIF link you refered has not updated datas.

IEC 61937 concern compressed non-linear PCM, so for AC-3, MPEG-1/-2 Audio, DTS, MPEG-2/-4 AAC, ATRAC, WMA, MAT.

An IEC 61937 compressed (such as, surround sound) audio stream at bit rates up to 24.576 Mbps. For bit rates above 6.144 Mbps, compressed audio streams conforming to IEC 61937 are carried using HBR Audio Stream Packets. Each packet carries four IEC 60958 frames, which corresponds to
(4x2x16 =) 128 contiguous bits of an IEC 61937 stream.

...

Properties of Digital Audio Signal at IEC 60958 Interface
‰Nominal frame rates
ƒBasic rates defined in [23] are 44.1 kHz (consumer applications) and 48
kHz (professional applications) Corresponds to 5.6448 and 6.144 Mbit/s,
respectively
ƒAlso define double, quadruple, half, and quarter rates in [23]
•Consumer applications – 11.025, 22.05, 88.2, 176.4 kHz
–Corresponds to 1.4112, 2.8224, 11.2896, and 22.5792 Mbit/s
»Bits are the UIs described above, and not the 2-UI bits
•Professional applications – 12, 24, 96, 192 kHz
–Corresponds to 1.536, 3.072, 12.288, and 24.576 Mbit/s

...
In fact, when i read IEC 60958 fastly, i saw that it support 16, 20 and 24 bit as expected and 8 kHz, 768 kHz as well, i never listen of the last one before though.

[Sami32]

@Nadahar Could you try with something like that:
fmpeg -i InputFile -ar 44100 -ac 2 -acodec pcm_s16be -f dvd

Just to verify if it's come from format standard compliance.

EDIT: Foobar2000 was not able to stream them correctly to your renderer ?

In case it could come from your Onkyo configuration, nice btw ;-) , i saw that in your manual:
Set your DVD/BD player’s HDMI audio output setting to PCM.

Listening Modes:
2-channel linear PCM (32–192 kHz, 16/20/24 bit).
Available sampling rate for PCM input signal is 32/44.1/48/88.2/96/176.4/192kHz.
Incompatible files cannot be played.

Listening Mode Preset
Analog/PCM: With this setting, you can specify the listening mode to be used when an analog (CD, TV, LD, VHS, MD, turntable, radio, cassette, cable, satellite, etc.) or PCM digital (CD, DVD, etc.) audio signal is played.
Multich PCM: Specifies the default listening mode for multichannel PCM sources input via a HDMI IN, such as DVD-Audio.

Music Optimizer:
The Music Optimizer function only works with PCM digital audio input signals with a sampling rate below 48 kHz and analog audio input signals. The Music Optimizer is disabled when the Direct or Pure Audio listening mode is selected.

Internet radio:
LPCM (Linear PCM)
• Sampling rates of 8 kHz, 11.025 kHz, 12 kHz,
16 kHz, 22.05 kHz, 24 kHz, 32 kHz, 44.1 kHz,
48 kHz, 64 kHz, 88.2 kHz, and 96 kHz are supported.
• Quantization bit: 8 bit, 16 bit, 24 bit
• Number of channels: 2

[ExSport]

@Sami32 what I wanted to say was that ps3 is specific so it probably accepted lpcm2.0 content type or 1.0 or anything else in LPCM without thinking about it so on ps3 it just works when sent to external receiver.
The specific of ps3 is that you can set to pass via HDMI or SPDIF any pcm stream without touch so when ps3 detected or was fooled that audio is pcm, it automatically passed through audio outside ps3 audio DAC.
Because of that maybe my testing of 5.1/7.1 on ps3 is not relevant for majority of renderers so I pointed it out.
Same way I pointed out some older thoughts from Shagrath about encapsulating HDaudio in EIC standards so someone will not go by blind way, nothing more. I don't have further knowledge here so tried to link some good thoughts for someone clever:)

[atamariya]

I think the discussion is going too far from LPCM.

When I try to transcode the same file with the same options (only -f wav instead of -f sb16be and a filename instead of pipe), the files play normally in all the media players I've tested.

This pretty much sums it up. LPCM in DLNA stream with "audio/L16" mimetype is something that doesn't work - or atleast I've not seen that working. That begs the question, in FFMpegAudio, when is the following scenario ever useful?

} else { // default: LPCM / L16 cmdList.add("-f"); cmdList.add("s16be"); // same as -f wav, but without a WAV header }

[Nadahar]

@atamariya audio/L16 does work. I've used foobar2000 for testing (since both my Onkyo and PS3 is far away from my development computer). Try it and you will see.

[Nadahar]

@Sami32

So, your are wrong, it's doesn't disable resampling at all, just toggle between 44.1 and 48 kHz LPCM resampling strictly DLNA compliant. If you really want disable resampling just add a line in your UMS.conf: 068698f

I think I have to explain again. For this bug to reveal itself, you have to test "non standard" files. That means not 44,1 or 48 kHz files or more than 2 channels. If you stay within the mentioned limitations the playback is fine.

I'm not sure what you mean by resampling. It has to be transcoded/converted obviously, as there is no file format for raw LPCM. You can't just mux to LPCM, so if that's what you mean by resampling that has to be on. But, you have to turn off "resample to 44,1 or 48 kHz" because otherwise the bug won't reveal itself since 44,1 or 48 kHz stereo works just fine.

Thanks for clarifying Foobar2000 use; i confess that i don't use it but only knew that it have excellent reputation from music lovers. Did you take a Wireshark capture ? or log ?

I don't use foobar2000 for anything but testing UMS. I'm sure it's a fine music player, but I don't have the need. I installed it exactly because it can function as a DLNA renderer.

This issue is over a year old. I don't remember exactly what I did or did not do, but I can assure you that I checked a lot of logs while trying to figure out what was going on. There were nothing obvious. As to a Wireshark trace I doubt I did that since it's unlikely that it would reveal anything. There are now "errors" in that sense, the files do play, it's just that the playback speed/pitch is wrong.

[Sami32]

@Nadahar For me they just play fine, but i dicovered an anomaly in my log though...

I mean you can select or unselect this option, it will be resampled in strick DLNA standard anyway.
If you don't believe me just check your Wireshark session.
I used resampling just because it's named like it, but your are right in reality it's transcoding, just tried to avoid confusion.

But the interesting point is that now i finally understood that your problem is with 48 kHz LPCM
EDIT: Sorry i mean 44.1 kHz

P.S. The developpers are the worst when it come to give log :wink:
44,1 or 48 kHz are all working fine for me ;-)

[Nadahar]

@Sami32 Are you saying that you can play e.g a 8 kHz mono WAV file transcoded to LPCM and it's playing in the correct speed even when resample to 44,1 or 48 is turned off?

[Sami32]

@Nadahar You never told that it need to be "mono WAV" ? or i didn't understood.
Whatever it will change nothing, for me "Automatic audio resampling" to 44,1 or 48 kHz work perfectly.
Any files i tried, for WAV i just tried now 8 and 22 kHz stereo; so feel free to send me mono.

[Nadahar]

What I'm trying to say is that you have to turn off automatic resampling to 44,1 or 48 kHz for the bug to occur. I don't remember exactly which files failed, but I remember that some of them were mono. It doesn't have to be mono though, I specificly remember the bug also with 6 channel audio transcoded to LCPM.

[Sami32]

6 channels WAV DTS are finely transcoded to LPCM for me.
What i tried to said is what you call "turn off" is toggling between 44.1 and 48 kHz.

[Nadahar]

I took the trouble of checking out the latest UMS snapshot, the bug is still there when testing on my Onkyo. After testing some of my test files, I soon come across a couple with this bug. There are many more, these are just examples.

QuickTime_test5_LPCM_Stereo_VBR_16SS_192000Hz.wav.txt

Complete name                            : QuickTime_test5_LPCM_Stereo_VBR_16SS_192000Hz.wav
Format                                   : Wave
File size                                : 7.60 MiB
Duration                                 : 10s 375ms
Overall bit rate mode                    : Constant
Overall bit rate                         : 6 144 Kbps

Audio
Format                                   : PCM
Format settings, Endianness              : Little
Format settings, Sign                    : Signed
Codec ID                                 : 1
Duration                                 : 10s 375ms
Bit rate mode                            : Constant
Bit rate                                 : 6 144 Kbps
Channel(s)                               : 2 channels
Sampling rate                            : 192 KHz
Bit depth                                : 16 bits
Stream size                              : 7.60 MiB (100%)

QuickTime_test7_LPCM_Stereo_VBR_16SS_192000Hz.wav.txt

Complete name                            : QuickTime_test7_LPCM_Stereo_VBR_16SS_192000Hz.wav
Format                                   : Wave
File size                                : 796 KiB
Duration                                 : 1s 61ms
Overall bit rate mode                    : Constant
Overall bit rate                         : 6 148 Kbps

Audio
Format                                   : PCM
Format settings, Endianness              : Little
Format settings, Sign                    : Signed
Codec ID                                 : 1
Duration                                 : 1s 61ms
Bit rate mode                            : Constant
Bit rate                                 : 6 144 Kbps
Channel(s)                               : 2 channels
Sampling rate                            : 192 KHz
Bit depth                                : 16 bits
Stream size                              : 796 KiB (100%)

[atamariya]

@Sami32 Can you confirm on your renderer that it's showing the stream as PCM similar to how it's marked MP3 below?

[Nadahar]

I can't see anything on your picture, but my renderer report them both as PCM 16bit/44.1kHz. It says briefly before playback starts however PCM 192kHz but it is quickly changed to 16/44.1. That means that the mimeinfo probably corretly sets it to 192kHz, but that the stream content for some reson is analyzed to not containt that.

[Nadahar]

Here is another file with the same bug - it's too big to upload, but the media info is:

Complete name                            : 08 - Depeche Mode - Jazz Thieves-d2p-p2p.flac
Format                                   : FLAC
Format/Info                              : Free Lossless Audio Codec
File size                                : 148 MiB
Duration                                 : 2mn 55s
Overall bit rate mode                    : Variable
Overall bit rate                         : 7 059 Kbps

Audio
Format                                   : FLAC
Format/Info                              : Free Lossless Audio Codec
Duration                                 : 2mn 55s
Bit rate mode                            : Variable
Bit rate                                 : 7 059 Kbps
Channel(s)                               : 6 channels
Sampling rate                            : 88.2 KHz
Bit depth                                : 24 bits
Stream size                              : 148 MiB (100%)
Writing library                          : libFLAC 1.2.1 (UTC 2007-09-17)

This is reported by the renderer as PCM 16bit/88.2kHz.

[Nadahar]

@Sami32 To make you extra happy, here is the log from the session testing the above files:
debug.log.txt

Unfortunately I forgot to turn on trace logging before I started.

[Sami32]

@Nadahar Thanks a lot :wink:

Ok, so now i understand that we was not talking about the same thing.

If i understood correctly, you can make "Use LPCM for audio" working when only when disabling "Automatic audio resampling", right ?

P.S. I'm like Saint Thomas d'Aquin, i believe what i see :wink:

EDIT: I loved too much your samples :laughing: i deserve that...
Sorry for all my misunderstanding 8-/ but i told you before, log...we have a proverb that could be translate by something like that: "a picture is worth thousand explanations"
I will try your way.

[Sami32]

@Nadahar So, i tried again with your files, and it's worked for me.

BUT, since my TV support WAV up to 48 kHz, your files files needed to become resampled, normal you could say, but not really...because they use my render configuration s:48000 as expected, and since i never tried without this parameter before.
So when i decided to delete it, i saw that "Automatic audio resampling" was not affecting your WAV files.

Audio_resample value change as expected in my UMS.conf but doesn't resample anything since it's for use with TranscodeAudio=LPCM; so i doesn't understand as it could affect you...
I can just guess you renderer configuration though, anyway, i suppose that i'm not the only one for who it's working ?

Are you able to reprocuce this issue with an other renderer like your TV ?

And i can listen very well how you are teasing me :stuck_out_tongue_winking_eye:
Anyway, a full log zip will make things more clear to me.

EDIT: For now, what i understood, guessed, is that using "Use LPCM for Audio", TranscodeAudio=LPCM together with "Automatic audio resampling" = true give you an audio issue while playing on your Onkyo, is that correct ?

[Nadahar]

@Sami32 To give you some context, I found this error when testing audio formats while working on #735. The problem isn't my Onkyo, it can play most formats natively (it doesn't need transcoding for wav or flac). When I test something I try to test as thoroughly as possible, and as a part of this testing I made a renderer configuration that transcoded everything into LPCM (I did the same for wav and mp3 but they don't suffer from this bug). My renderer configuration is therefore without any "supported" lines in this test, I want everything to be transcoded to LPCM. The FFmpeg Audio setting for "Automatic audio resampling to 44.1 or 48" is off/false.

I don't have a DLNA capable TV (I honestly don't see the need), but the bug is the same with my Onkyo and foobar2000 indicating that it's not a renderer issue. I don't think I ever tested this with my PS3 as I bought that (second hand) later for testing UMS only. I rarely use the PS3 though, I generally hate consoles and having some corporate overlord telling you what you can and can't do. Given that the PS3 does a lot of strange things I don't really know if a test with it is even relevant to determine if there is an issue here.

When I use a proper renderer profile for my Onkyo the files play just fine, but that's because they are then streamed. Since I have a proper 1Gbps network LPCM is my preferred transcoding format since it's lossless/RAW, but I could just use wav instead to get around this issue. That has never been my goal though, my goal is to find and correct errors that will apply for example for a renderer that doesn't accept wav and for those that don't want the massive quality loss induced by mp3.

[Nadahar]

I took the trouble of testing this with the PS3 as well. The PS3 won't play the files at all, just gives a general error message about being able to play the file. The result is the same with the standard PS3 renderer config or my special "transcode all" config.

Enjoy: ums_debug.zip.txt

[Sami32]

@Nadahar Do you see how much posts could be saved with just a full log :wink:

Could you send me your tweaked renderer configuration ?
All the pieces of the puzzle are welcome.

Delete the lines with TranscodeAudio=LPCM and Supported f:lpcm .... and try again, as L16 is per standard RFC 3555, my Panasonic Viera accept l16 though, but maybe your Onkyo doesn't, so just discard that parameter from the equation. Don't change just delete, leaving UMS handle it by default.

I do think your renderer is able to receive it, so it would be nice for all music lovers having good audio renderers like your, to beneficy of the best audio quality possible.

EDIT: Your log doesn't look like mine, it's DLNA standard compliant.

[Nadahar]

@Sami32 I've posted two logs here now, the first one while playing test files that gives wrong pitch (debug only). The second one is full trace but is only while I was trying to play the same files on the PS3 which failed. I don't know which of these you refer to as DLNA compliant.

My tweaked renderer configuration for the PS3 was simply to remove all the "supported lines". Unless I'm mistaken, TranscodeAudio default to LPCM so it doesn't need to be specified.

My tweaked configuration for my Onkyo was very simple:

Video = false
Image = false
SeekByTime = true
WrapDTSIntoPCM = true
HalveBitrate = true

MediaInfo is not used in this configuration, but I just did this quickly now. I'm 99% certain that earlier tests using MediaInfo gave the same results.

[Sami32]

@Nadahar m:audio/l16 just need to be replaced by m:audio/L16 in you renderer configuration, my guess though...from the only one trace log sended.
That's said it's not the root of this problem, as i finally was able to reproduce it with some files :-)

I think i identified the problem, so just to be sure, could you send me, please, some more problematic audio files (not too big) classed by "speedy" and "slowly".

Could you try these audio files, test if you can reproduce it and give me feedback:
ghostbuster.wav.txt (speedy)
SURROUNDTEST_DTS-6ch.wav.txt (slowly)

EDIT: BTW, if you disable "Use LPCM for audio" you get the same problem on some WAV files, right ?

Do you get exactly the same result on all your problematic WAV files if you use this FFmpeg version ? (like your QuickTime_test5_LPCM_Stereo_VBR_16SS_192000Hz.wav and the other one sended or with my samples). It will help me narrowing definitively this issue.
https://ffmpeg.zeranoe.com/builds/win64/static/ffmpeg-20160714-f41e37b-win64-static.zip

P.S. Don't worry, after that i will not need any more test or files from your side ;-)
IMHO, It's an FFmpeg or codecs renderers support issue, but i think we could easily get around it. MediaInfo is not able to report that deep on the used WAV codecs.
The fact that in your log FFmpeg had levelog set to warning mode did not helped...

[Sami32]

@SubJunk I think that adding the codec in FFmpeg with -acodec pcm_s16be will do the trick, as the _s16be_ format can have many different codecs, and as i discovered they are not all well supported by renderers when included in raw LPCM, like u8 or fltp by my Panasonic for example.

Since you and @valib are much more knowledgable about FFmpeg, and each of you have powerful computers :wink: ...

EDIT: On my 2 samples i saw that one was 8 bit unsigned and the other 24 bit.
So i was not sure which one was causing this but now with the news sample from @Nadahar perhaps i will be able to narrow more this issue.

[Nadahar]

@Sami32 Your ghostbuster sample isn't speeded up when I test it, but the Swedish surround test is slowed down so much that I can't hear what it is.

It's very time consuming to find more examples as most of them play correcly after #729, but after listening to about 100 samples I found some:
Slow: ForUntoUsSurround88.flac.txt
Slow: surround88.flac.txt
Slow: test192.flac.txt
Slow: test192.m4a.txt

[Nadahar]

@Sami32 The FFmpeg version you linked to made no difference whatsoever. Did you have a specific reason to ask me to test that version, or was it just a general "maybe the latest version have fixed it"? If the latter, I'm not willing to do such "wishful" tests without any specfic reason why something would have changed. Everything takes time to do, and life is just too short to try blindly testing all possible combinations of things.

I think you will find the same with many users. If you just keep asking them to try things with a very low probability of success (or without a specific reason to other than that some piece of software is newer), they will quickly stop wanting to help solve a problem. My general claim stays the same: If noone did something to address a given problem, it very rarely "solves itself" by coincidence.

[Nadahar]

@Sami32 I checked out your test_patch branch and ran that, and the problem remains the same (but it might solve other problems).

[Nadahar]

What i tried to said is what you call "turn off" is toggling between 44.1 and 48 kHz.

Not as I recall it. The way I remember it is that if you enable this option, transcoding to 44.1 or 48 kHz will be activated. Whether 44.1 or 48 kHz will be used depends on the renderer configuration.

[Sami32]

@Nadahar Thanks for sample, i thought that as you make this issue and told that you have many you'll have many samples. I appreciate your support :wink:

Yes, i did have a reason, other that your ASS subtitles will love it, is that i can compare the effect with mine, as different version could have a different bug, so since you was not able to play the first samples that you sended it's mean that our different experience come from our renderer specifications.

_test_patch_ is just a personnal test to make it work, that i need to narrow with the informations of all the audio files giving problem. It didn't work for me as well, that good, it's just narrowing the problem a little more ;-)

Sorry, you was right with "turn off".

[Nadahar]

@Sami32 Because of #999 I'm not able to test the latest with foobar2000, but the fact that I had the same results with my Onkyo and foobar2000 in earlier versions indicate to me that it isn't an Onkyo bug. That said, the PS3 won't play them at all so it's hard to know what conclusion to draw.

[Nadahar]

I think the problem might be as simple as UMS not keeping to the DLNA profiles that the renderers expect a media server to respect. What happens when you break these rules might be arbitrary, some might refuse to play while others might play them with or without errors.

LPCM has 3 profiles:

| Profile ID | Description | MIME type | Label |
| --- | --- | --- | --- |
| LPCM | Profile for audio media class content | audio/L16 | 2-ch |
| LPCM_low | Profile for audio media class content | audio/L16 | 2-ch |
| LPCM_MPS | Profile for audio media class content with up to 7.1 channels | audio/L16 | multi |

Detailed profile descriptions below:

8.4 LPCM profiling guidelines

8.4.2 LPCM audio format

8.4.2.1
[PROFILES]
LPCM

8.4.2.2
[GUIDELINE] This audio format specification shall follow profiling of IETF RFC 3555, which defines the MIME encapsulation for the LPCM DLNA media format and uses the "L16" audio media format defined by IETF RFC 3551. "L16" denotes uncompressed audio data, using 16 bit signed representation in two's-complement notation and network byte order.

There are the following parameter constraints to "L16" as defined by DLNA.

Sampling rates:

• 44,1 kHz
• 48 kHz

Content audio channel modes:
A bitstream conformant with this media format profile may contain the following formats

• Mono (1)
• Stereo (2)

Quantization:

• 16 bit

[COMMENT] Sample rate and the number of channels parameters are provided in the MIME type header. The "channels" parameter is not required by IETF RFC 3555. The default channel ordering for 2 channel content is:
Channel 1: Left
Channel 2: Right
as indicated by IETF RFC 3555.

8.4.3 LPCM audio format: Transport Alignment Position

8.4.3.1
[PROFILES]
LPCM
LPCM_low
LPCM_MPS

8.4.3.2
[GUIDELINE] The Transport Alignment Position for bitstreams conformant to this profile shall be the sample boundary. For monaural streams this is a 16 bit sample, and for stereo streams this is a pair of 16 bit samples, one for each channel.

[COMMENT] Channel order for Stereo bitstreams is defined in 8.4.2.

8.4.4 TLPCM audio format: MIME type definition

8.4.4.1
[PROFILES]
LPCM LPCM_low LPCM_MPS

8.4.4.2
[GUIDELINE] MIME type "audio/L16" shall be used for this Media Format Profile.

The "channels" parameter should be included in the MIME type header exposed by a Serving Endpoint.

The value of the "channels" parameter directly corresponds to the number of channels of the core LPCM stream, i.e. either 1 for Mono or 2 for Stereo.

If a Serving Endpoint does not include the "channels" parameter in the MIME typeheader, the default value assumed by the Rendering Endpoint shall be 1. If the number of channels in the core LPCM stream is 2 then the Serving Endpoint must indicate this in the MIME type header so that the Rendering Endpoint is always able to correctly determine the number of channels

The "rate" parameter shall be included in the MIME type header exposed by the Serving Endpoint.
For LPCM_MPS content, the value of the "channels" parameter directly corresponds to the number of channels of the core LPCM stream, i.e. either 1 for Mono or 2 for Stereo.

[COMMENT] An example MIME type for stereo core LPCM with MPS and 48 kHz sampling rate is:

audio/L16;channels=2;rate=48000

This Guideline specifies that a Serving Endpoint must expose only the MIME types of the partial parameter sets it supports in the CMS.SourceProtocolInfo instance state variable, see Guideline 6.1.7.4. If, for example the Serving Endpoint supports mono LCPM at sampling rates of 44,1 kHz and stereo at 48 kHz then it needs tolist only the following information in the protocolInfo :

http-get:_: audio/L16;channels=1;rate=44100:DLNA.ORG_PN=LPCM
http-get:_: audio/L16;channels=2;rate=48000:DLNA.ORG_PN=LPCM

or

http-get:_: audio/L16; rate=44100:DLNA.ORG_PN=LPCM
http-get:_: audio/L16; channels=2; rate=48000:DLNA.ORG_PN=LPCM

since the channels parameter may be omitted for a mono stream.

8.4.5 LPCM audio format: Rendering Endpoint capabilities

8.4.5.1
[PROFILES]
LPCM_MPS

8.4.5.2
[GUIDELINE] Rendering Endpoints compliant with this DLNA media format profile shall also be able to render content indicated by the following profiles:

• LPCM
• LPCM_low

8.4.6 LPCM audio format: MPS signaling
8.4.6.1
[PROFILES]
LPCM_MPS

8.4.6.2
[GUIDELINE] A bitstream conformant with this profile shall follow the transport and signaling requirements for MPEG Surround as Buried Data in a PCM bitstream as specified in ISO/IEC 23003-1:2007, 7.3.

8.4.7 LPCM audio format: low

8.4.7.1
[PROFILES]
LPCM_low

8.4.7.2
[GUIDELINE] The DLNA LPCM_low audio format profile shall conform to all aspects of the LPCM profile except as noted here:

Sampling rates:

• 8 kHz
• 11,025 kHz
• 12 kHz
• 16 kHz
• 22,05 kHz
• 24 kHz
• 32 kHz

8.4.8 LPCM audio format: MPS

8.4.8.1
[PROFILES]
LPCM_MPS

8.4.8.2
[GUIDELINE] A bitstream conformant with the DLNA LPCM_MPS audio format profile shall conform to all aspects of the LPCM profile as specified in 8.4.2 or the LPCM_low profile as specified in 8.4.7.

8.4.8.3
[GUIDELINE] MPS encoding shall match the provisions for one of the following levels in the MPS profile as defined in ISO/IEC 23003-1.

• MPS Baseline Profile at Level 1
• MPS Baseline Profile at Level 2
• MPS Baseline Profile at Level 3
• MPS Baseline Profile at Level 4

Maximum sampling rate

• 48 kHz

Content audio channel modes

• Mono (1)
• Stereo (2)
• Multichannel (3)
• Multichannel (4)
• Multichannel (5)
• Multichannel (5.1)
• Multichannel (7.1)

Maximum bit rate (informative)

• 1 536 kbit/s

Quantization

• 16 bit

[COMMENT] PCM is used for up to 2 core channels. MPS Levels 1 to 4 allow different numbers of input and output channels, and a different bandwidth of the residual signal decoding. The inherent bitstream level compatibility of MPEG Surround makes it possible for decoders of level 1, 2, 3 and 4 to decode bitstreams of all levels, though at a possibly slightly reduced quality due to the limitations of the decoder. This means that the highest possible reproduction quality is only ensured when the level of the decoder is equal to or larger than the level of the bitstream.

[Nadahar]

While these standards manage to write the simplest things in complicated ways, I see nothing about support for anything but 16 bits or sample rate above 48 kHz. Anything above two channels has to adhere to the MPS profile.

[Sami32]

@Nadahar Like you repeat, never presume :wink:
Note: These LPCM_Low and LPCM_MPS profiles coming from IEC 62481-2 (09/2013) standard have disappeared from 2016 DLNA edition, that will enter in force very soon, but some nice other profiles support was implemented though :-)
So before saw the definitive IEC 62481-2:2017, i will use minimum strict standard compliance for now.

EDIT: Your _surround88.flac_ (24 bit, s32) sample is the only one giving me issue, "slowlyness".
I think that in your case 90% of your problem could be solved by a renderer configuration, just a guess though...
Supported = f:lpcm a:lpcm n:2 s:48000 b:1536000 m:audio/L16

[Nadahar]

@Sami32 I don't get why you think that would make a difference. The supported lines decide whether media will be streamed or transcoded. This is already transcoded as part of the test. I think you think the "supported" lines are more advanced than they actually are.

[Sami32]

TranscodeAudioTo441kHz = true for PS3 in your renderer configuration could help, maybe...

I mean that it will select the LPCM non-standard compliant files to be transcoded by my patch that i didn't test yet. Maybe you will test it before me :wink:

Hoping for the best...but i suspect a FFmpeg codec tricky issue or tricky parameters...

[Nadahar]

@Sami32 This isn't really about the PS3 issue, I have my PS3 configured to 48 kHz so I doubt that will work. In any case, I've used the default PS3 renderer configuration but "Resample audio" probably need to be turned on for that to work.

[atamariya]

@Nadahar Apparently encoding with two channels (-ac 2) allows you to play LPCM streams without issues. Without that option, ffmpeg retains ALL the channels and renderers fail to play anything more than 2 channels via UPnP. Let me know if that works for you two or you see any problems with any of your samples.

[Nadahar]

@atamariya This issue was never about when using "audio resampling". If you see the profiles above, there are valid LPCM profiles for multichannel LPCM, but none above 48 kHz. According to @Sami32 some renderers still support it though, but my guess is that my remaining "problem files" are due to too high sample rate. #729 solved most of this issue, but some files still played with wrong speed and it seems like that's high bitrate files only.

I as I see it I now know what's causing this issue, that LPCM streams supplied are out of spec/renderer support and is attempted played as if they had a lower sample rate. It makes sense that doing that results in a low pitch.

The question is if it should be solved and if so, how. One possibility is to use the renderer configuration to limit the LPCM stream (that is, transcode it "down" if some values are too high for the renderer), but I know that updating renderer configurations to get this correct will take ages and probably never be fully implemented. As pointed out before I also thing the current syntax for the "supported" lines is too limited. Another way is "your way" using the supported protocols given by the renderer. I don't know how accurate the renderers are when they report this, but that could give a good solution retaining as high quality as possible while ensuring compatibility. That would however take a lot of rewriting, and would probably be best implemented if your "zero config transcoding" is merged.

This could just stay open until then for me, unless someone feels the need to implement it via renderer configuration. I don't, as I see it as a solution that will never work well. The most important thing for me is that I now think I know why this is happening.

[Nadahar]

This is caused by a severely lacking DLNA implementation breaking specification rules and not giving proper information to the renderer. Will most likely never be fixed.

[SubJunk]

Closing issues with a lot of detail like this isn't desired. It is still a relevant issue to have open and may be worked on.

[Nadahar]

The information is still available if it is closed. It's more about me signaling that I no longer expect this to be fixed. Even when I tried to figure it out, it's been ignored for years - are you saying that now that I no longer have any intention to try to solve it, you will suddenly care about it?

[SubJunk]

To me, closed means don't work on it. If something is a bug, it should have an open issue, especially given that we have new developers showing interest in the project, they might find this useful.