I've submitted the bug report to ffmpeg devs. Hopefully it will get some
attention sooner rather than later given that the fix has been handed to
them.
https://trac.ffmpeg.org/ticket/7291
Thanks for all your help.
Very much appreciated.
bpa wrote:
> The author of the ffmpeg bug report says his problem 24bit file was NOT
> created by ffmpeg - I find that amazing - same bug in two different
> apps. If that is really the case, then I'll post ffmpeg bug report to
> fix the ffmpeg ALAC 24bit create issue
But he is kinda vague on
pssturges wrote:
> FWIW my testing of your patch works well. Files produced have the bit
> depth atom set correctly to 24bit. LMS scans the files as 24bit and they
> play correctly. No white noise!
>
> I'm very happy.
That's good - independent build and test is reassuring.
The author of the
bpa wrote:
> I had a few hiccoughs getting the build to complete. I haven't
> regression tested the patch against test file but I think it should be
> OK as it is carryin over sample size just like Flac and 8,16,24 and 32
> are all technically valid in ALAC (not sure if alac encoding routine
>
pssturges wrote:
> Well that's one hell of a coincidence if that's the case!
Coincidences happen. A few years I spent weeks tracking down a bug
eventually to a RealAudio codec part of ffmpeg, I worked out a solution
then I posted it. A day or so later, the maintainer of the RealAudio
codec
bpa wrote:
> I think it is the same but badly worded.
>
> The writer says their 24 bits alac file when examined by the
> Audiotoolbox (i.e. Apple not ffmpeg libraries ) application say it is
> 16bit.
> The attached test source file has the same alac atom error as a ffmpeg
> created alac file
pssturges wrote:
> No, not mine. Haven't got around to it yet. Although it seems similar
> and perhaps related, it doesn't seem quite the same?
I think it is the same but badly worded.
The writer says their 24 bits alac file when examined by the
Audiotoolbox (i.e. Apple not ffmpeg libraries
No, not mine. Haven't got around to it yet. Although it seems similar
and perhaps related, it doesn't seem quite the same?
pssturges's Profile: http://forums.slimdevices.com/member.php?userid=66790
View this thread:
Is this your ffmpeg report or just a coincidence ?
https://trac.ffmpeg.org/ticket/7287
bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806
View this thread:
Glad the fix worked for you.
If you want to suggest a fix to ffmpeg developers (or build your own
ffmnpeg) - the following is what I think fixes the change
In the file *libavformat/movenc.c*
Code:
1081,1083c1085
<
< if
pssturges wrote:
> Any ideas if it would be possible to make the edit as a find and replace
> or something similar in my script? I've never done hex editing.
Hex editing is just editing a file as a series of bytes and altering
values by typing in hex value of a byte (e.g. 0x41 instead of 'a') -
pssturges wrote:
> Thanks, yeah thats the idea. I want make sure I give them the best info
> possible to increase the chances of getting it fixed in a timely manner,
> although there does seem to be a LOT of outstanding tickets so I'm not
> holding my breath.
Getting a fix for ffmpeg would be
bpa wrote:
> I use mp4file with --dump which display the tags in a tree form but
> collapses long arrays (e.g. offset table) but if I want more detail add
> the debug (-d ?) option.
> I hope this is so that you can file a bug report with ffmpeg developers.
>
>
> I've looked at ffmpeg code
Paul Webster wrote:
> Have you tried http://atomicparsley.sourceforge.net/ to dump the fields?
Yeah I have. Haven't been able to get anything useful out of it yet. I
get this:
Code:
phil@htpcserver:~/Downloads/test$ AtomicParsley test.m4a -t 1
Major Brand: M4A -
pssturges wrote:
> So a lot of info tools seem to analyse the data rather than use the
> header? ffmpeg clearly does and shows 24bit. Below is the mediainfo
> output. That would be from analysing the audio stream rather than the
> header? I would like to be able to have a closer look at the
Have you tried http://atomicparsley.sourceforge.net/ to dump the fields?
Paul Webster
http://dabdig.blogspot.com
Author Radio France (FIP etc) plugin
Paul Webster's Profile:
So a lot of info tools seem to analyse the data rather than use the
header? ffmpeg clearly does and shows 24bit. Below is the mediainfo
output. That would be from analysing the audio stream rather than the
header? I would like to be able to have a closer look at the header. Are
there any tools
I know why it works for players. Once a player is told by mpeg4 header
that it is playing ALAC, the player uses an ALAC decoder and starts
decoding the stream it will discover the sample rate and size as it is
encoded in the audio data. Not all formats have the sample size encoded
in the
pssturges wrote:
> Just thinking, would it be more reliable for the LMS scanner to get this
> info from elsewhere in the file as apparently other software seems to?
AFAIK The alac atom is where the information is supposed to be. It is
there when the proper software (i.e. using Apple libraries)
Just thinking, would it be more reliable for the LMS scanner to get this
info from elsewhere in the file as apparently other software seems to?
pssturges's Profile: http://forums.slimdevices.com/member.php?userid=66790
OK excellent. Good to get to the bottom of it. Just curious what tool
you're using to get that atom info? The tools I've tried only show my
file as 24bit.
I've had a look at the ffmpeg open bug reports and none seem to be
related to this so I'll do a report once I can show that the tag shows
Previously I've done a bit of work with internal coding of MPEG4 files
so I know my way around. MP4 have a data structure which is a tree made
up of "atoms".
The "alac" atom describes the details of the alac encoding and there is
a difference between working MP4 and the file created using
bpa wrote:
>
>
> A quick check seems to show there is a something in the "good" ALC file
> that marks it as "Hires Lossless" but it is missing in the ffmpeg file.
> This may be just a comment or somehting special.
>
Yeah, thats my own personal edit of the comment field.
Thanks for all
pssturges wrote:
> No, everything from 44.1kHz -192kHz
>
> Is this useful? All tracks played were 24bit ALAC and played correctly.
Yes - it shows fiels is identified as alac and nothing special happens
in transcode
> Here is the file shown in the last ffmpeg output. This plays correctly
>
bpa wrote:
>
> Are the working files all 96kHz ?
>
No, everything from 44.1kHz -192kHz
Is this useful? All tracks played were 24bit ALAC and played correctly.
https://pastebin.com/WKwkyRP4
Here is the file shown in the last ffmpeg output. This plays correctly
form me.
You swapped threads - I was following my reply which was to another
thread (lucky I spotted it) - I did not read the preceding stuff in
this thread which may or may not be relevant.
There is something else going on and it is not just to do with s32le vs
s32be as the file you sent is the same
bpa wrote:
> > pssturges wrote:
> > I think I mostly follow what you are saying here, but are you referring
> > to all 24 bit alac files? I have many other 24bit alac files encoded
> > using other encoders and they play just fine and the receiver reports
> > them as being 24bit.[/qupote]
> >
pssturges wrote:
> I think I mostly follow what you are saying here, but are you referring
> to all 24 bit alac files? I have many other 24bit alac files encoded
> using other encoders and they play just fine and the receiver reports
> them as being 24bit.[/qupote]
> You didn't mention working
bpa wrote:
> I have a number of data points but IMO the bottom line is that LMS will
> not play 24bit ALAC trancoded to PCM without changes to LMS code. There
> is no problem playing ALAC transcoded as Flac.
>
> 24 bit Flac transcoded to PCM by flac will play in ffplay if S32le is
> chosen.
>
I have a number of data points but IMO the bottom line is that LMS will
not play 24bit ALAC trancoded to PCM without changes to LMS code. There
is no problem playing ALAC transcoded as Flac.
24 bit Flac transcoded to PCM by flac will play in ffplay if S32le is
chosen.
24 bit ALAC transcoded by
pssturges wrote:
> Apart from the time to set it up, are there any downsides to using
> ffmpeg rather than faad?
ffmpeg is swiss army knife - it has lots of functionality you'll never
use and so it can take up a lot of memory. It uses the same libraries
as faad - so audio output will be
bpa wrote:
> There are tow instances of playing a track.
>
> The first transcodes into MP3 using lame.
> >
Code:
> >
> [18-06-25 17:23:54.6388]
Slim::Player::TranscodingHelper::tokenizeConvertCommand2 (617) Using command
for conversion:
There are tow instances of playing a track.
The first transcodes into MP3 using lame.
Code:
[18-06-25 17:23:54.6388]
Slim::Player::TranscodingHelper::tokenizeConvertCommand2 (617) Using command
for conversion: "/usr/share/squeezeboxserver/Bin/x86_64-linux/faad" -q
bpa wrote:
> Anytime I have come across white noise from what should be an audible
> stream - it is due to a mistake in the expected byte order of audio
> samples (e.g. big endian vs little endian) or a mistake in the sample
> size (e.g. 16bit in 2 byte vs 24 bits in 3 bytes vs 24bits in 4
pssturges wrote:
> The only reason this is a significant issue is that these files produce
> white noise when played through UPNP/DLNA bridge.
Anytime I have come across white noise from what should be an audible
stream - it is due to a mistake in the expected byte order of audio
samples
I created a test file exactly like yours using ffmpeg and a test file
from 2L.
When playing the file to a SB player which is capabale of 48kHz - LMS
creates a trasncoding chain as follows:
Code:
"/xx/7.9/latest/trunk/Bin/x86_64-linux/faad" -q -w -f 1
pssturges wrote:
> Source is officially downloaded flac file from artist's website.
>
> >
Code:
> > ffmpeg -i -y -map 0:0 -c:a:0 alac test.m4a
> >
OK I can do a test conversion and see if I can replicate the results.
Source is officially downloaded flac file from artist's website.
Code:
ffmpeg -i -y -map 0:0 -c:a:0 alac test.m4a
pssturges's Profile:
>
> Stream #0:0(und): Audio: alac (alac / 0x63616C61), 48000 Hz, stereo,
> s32p (24 bit), 1752 kb/s (default)
>
I'm not familiar with s32p 24 bit but it seems an "odd" choice. How was
the file created ?
looking at ffmpeg output for "-sample_fmts" - s32p should have 32 bits.
I'll try to do
bpa wrote:
> Start with the first item.
>
> To understand what is really going wrong is it the scanning or the
> transcoding ? - provide the debug output of the scanner.log file for
> this problem file and then the server.log with player.source set at
> INFO when playing this file to a SB
tmtomh wrote:
> Wow - blast from the past!
>
> Thank you for bumping this - actually gives me an opportunity to correct
> a couple of factual errors (though none that bear on the substance of
> the issue):
> > >
- Max was not created by the same developer as XLD.
- XLD does in fact let
pssturges wrote:
> 1) LMS does seem to scan the files incorrectly and report the wrong
> properties. This seems clearly to be an issue with LMS
Start with the first item.
To understand what is really going wrong is it the scanning or the
transcoding ? - provide the debug output of the
bpa wrote:
> LMS is now community suipported so unless it is clearly an LMS and not a
> bridge problem, it may not get attention.
>
> To prove it is not a bridge problem, have you tested using something
> with a h/w SB player or Squeezelite on a PC ?
Well, I guess there is 2 parts to the
tmtomh wrote:
> Thanks for the input and helpful replies. I think I found the source of
> the problem, and it's a weird one: I discovered that every high-res file
> LMS showed with the proper 24-bit sample size had been encoded by XLD.
> And every one it showed as 16-bit had been encoded by
44 matches
Mail list logo
