Home of the Squeezebox™ & Transporter® network music players.
Page 3 of 3 FirstFirst 123
Results 21 to 22 of 22
  1. #21
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    21,016
    Quote Originally Posted by philippe_44 View Post
    I've pushed that PR https://github.com/Logitech/slimserver/pull/749, let me know if this works for you
    The update works and it is done in a way I prefer (i.e. looking for STCO 1st chunk) rather than hidden in Audio::Scan.
    In your comments you say "find optional stco" - according to spec "stco" is "mandatory".

    Quote Originally Posted by mherger View Post
    > I've pushed that PR https://github.com/Logitech/slimserver/pull/749

    Thanks a lot philippe_44! I'll wait for bpa's thumbs up before merging. Ok?
    A quick test with both Accuradio and Tidal MPEG-4 streams and they play OK.
    I'll do a bit more testing later today with MPEG-4 audio podcasts which are harder to find but have greatest variations.

  2. #22
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    21,016
    Summary: I think the PR can be merged.

    I did some more testing with a variety of m4a audio podcasts as well as some more Tidal (m4a) and Accuradio tracks. I'm summarising the results to record them somewhere, not to get more changes.

    All podcast I tested had an "stco" atom.

    A couple of podcasts didn't play on LMS but I think not related to the proposed fix (e.g. incorrect MIME type)
    http://images.anandtech.com/reviews/...odcast_048.m4a
    https://mbse-podcast.rocks/wp-conten...MPCT_19-24.m4a

    One podcast which played OK on LMS, had an "stco" atom but its offset was not used. This podcast had "moov" after "mdat" and so technically is not a streaming MPEG-4 file. Great that LMS managed to play it.
    https://www.smarterartschool.com/upl...0_12.04_pm.m4a

    I haven't seen any recent comments about non-playing m4a podcasts, so I think not necessary to make more changes.

    With regard to why there are extra 8 zeros in Accuradio mdat field - my current theory is related to the encoder implementation. Without knowing the total size of audio data when creating the header, the encoder is allowing for a very large mdat atom (i.e. audio data) which would require the 64 bit largesize field.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •