Understanding custom-convert.conf

[benh]

I'm trying to set up a custom-convert.conf rule to transcode all ALAC to FLAC for one specific player. This is related to my recent post in the DAC32 thread.

I'm running the Dockerized official LMS, Logitech Media Server Version: 8.1.2 - 1619728303 @ Fri Apr 30 00:34:35 CEST 2021

Here's my custom-convert.conf, which I pretty much lifted entirely from the alac->flac config in convert.conf:

alc flc * 7c:9e:bd:28:dd:c4
        # FT:{START=-j %s}U:{END=-e %u}D:{RESAMPLE=-r %d}
        [faad] -q -w -f 1 $START$ $END$ $FILE$ | [sox] -q -t wav - -t flac -C 0 $RESAMPLE$ -

which is included in LMS via this docker argument:

-v config/custom-convert.conf:/lms/custom-convert.conf:rw

convert.conf is factory stock.

With the above custom-convert.conf in place, LMS doesn't seem to match on it and files don't seem to be transcoded. I can see in the File Types settings that an additional FLAC method is added to the Apple Lossless section, so I know that LMS is seeing the configuration.

If I DISABLE the "native" method for Apple Lossless in File Types, files do get transcoded.

I understand that more specific rules take precedence over less specific rules.

Does custom-convert.conf take precedence over convert.conf?

Attached are logs from player.source.

[philippe_44]

LMS will apply the most convenient rule, in order. In your case, alac is a supported codec so it will look for an alc alc rule (as alc is the source). And because there is no need to resample, the identity rule (do-nothing) will be used

[benh]

Thanks, that confirmation is helpful. I had expected that a more-specific rule, such as in my custom-convert.conf would take precedence over the more general alc alc rule, but that seems not to be the case. I think it's a more specific rule because it specifies the MAC address of a specific player.

So, is it true that as long as a player asserts support for a particular codec, such as ALAC, LMS will always default to the (in this case) alc alc rule and do nothing?

And if I wanted to transcode ALAC to FLAC for only one specific player, I would have to disable the native ALAC support globally in File Types, write a rule to transcode ALAC to FLAC for that player, and then also write a fall through rule to pass ALAC through natively to all other players?

Is there documentation somewhere of the order of operations for conversion rulesets?

[benh]

And one more question: Is custom-convert.conf evaluated before or after convert.conf? Seems like it would need to be evaluated before for local rules to be applied.

[philippe_44]

And one more question: Is custom-convert.conf evaluated before or after convert.conf? Seems like it would need to be evaluated before for local rules to be applied.

Yes, custom-convert rules are evaluated before

[benh]

Thanks. I still don't quite understand order of operations, then.

Based on my (obviously) superficial understanding thus far, I would think that a transcoding rule like the one I specified above would be encountered first and be "more specific" than the alc-alc rule that appears in convert.conf. But maybe I'm incorrect in thinking that more specific wins over easiest, but I swear I read that more specific wins somewhere.

[slartibartfast]

Thanks. I still don't quite understand order of operations, then.

Based on my (obviously) superficial understanding thus far, I would think that a transcoding rule like the one I specified above would be encountered first and be "more specific" than the alc-alc rule that appears in convert.conf. But maybe I'm incorrect in thinking that more specific wins over easiest, but I swear I read that more specific wins somewhere.

Why don't you just change the playable formats for the DAC32 as mentioned earlier?

Sent from my Pixel 3a using Tapatalk

[benh]

Why don't you just change the playable formats for the DAC32 as mentioned earlier?

Sent from my Pixel 3a using Tapatalk

Fair question.

My first answer would be that I didn't see any way to do that with the Polyvection firmware. Not clear that that option is exposed, or at least I haven't heard of how.

My second answer would be that I kind of like the idea of addressing this issue centrally on the LMS rather than having to change playable format on what will likely be multiple esp32-based players.

My third answer would be because I'm interested not only in a solution to my issue, but in understanding the system overall. So this is now ALSO about understanding how custom-convert.conf and convert.conf work.

[philippe_44]

Thanks. I still don't quite understand order of operations, then.

Based on my (obviously) superficial understanding thus far, I would think that a transcoding rule like the one I specified above would be encountered first and be "more specific" than the alc-alc rule that appears in convert.conf. But maybe I'm incorrect in thinking that more specific wins over easiest, but I swear I read that more specific wins somewhere.

But I'm confused - the rules above is "alc flc", not "alc alc", so if there is no reason that the alc flc rule would be used

[benh]

But I'm confused - the rules above is "alc flc", not "alc alc", so if there is no reason that the alc flc rule would be used

I think I'm confused.

What I think I heard you say earlier is that if a player asserts that it supports, say, native ALAC decoding, LMS will find the alc alc convert.conf rule, stop there, do nothing since nothing is what is called for, and send ALAC straight to the player.

I want to change the behavior for a specific esp32 player that asserts that it supports native ALAC decoding. Instead, I want to transcode ALAC to FLAC before sending it to that player, and that player only, no matter what the player says it can handle. I thought that I could create a custom-convert.conf rule for that player that tells it to transcode ALAC to FLAC, hence the rule I reference above.

[slartibartfast]

Fair question.

My first answer would be that I didn't see any way to do that with the Polyvection firmware. Not clear that that option is exposed, or at least I haven't heard of how.

My second answer would be that I kind of like the idea of addressing this issue centrally on the LMS rather than having to change playable format on what will likely be multiple esp32-based players.

My third answer would be because I'm interested not only in a solution to my issue, but in understanding the system overall. So this is now ALSO about understanding how custom-convert.conf and convert.conf work.

OK but you seem to have loaded the SqueezeESP32 firmware based on other posts.

Sent from my Pixel 3a using Tapatalk

[benh]

OK but you seem to have loaded the SqueezeESP32 firmware based on other posts.

Sent from my Pixel 3a using Tapatalk

That is true. However, I started down this rabbit hole before I did that, so I'm still trying to understand how transcoding configuration works, because I clearly do not, and I want to know.

I like music. I like learning things. Here, I am doing both, or at least trying.

[slartibartfast]

That is true. However, I started down this rabbit hole before I did that, so I'm still trying to understand how transcoding configuration works, because I clearly do not, and I want to know.

I like music. I like learning things. Here, I am doing both, or at least trying.

Good luck, at least you know you have a fall back [emoji2]

Sent from my Pixel 3a using Tapatalk

[philippe_44]

I think I'm confused.

What I think I heard you say earlier is that if a player asserts that it supports, say, native ALAC decoding, LMS will find the alc alc convert.conf rule, stop there, do nothing since nothing is what is called for, and send ALAC straight to the player.

I want to change the behavior for a specific esp32 player that asserts that it supports native ALAC decoding. Instead, I want to transcode ALAC to FLAC before sending it to that player, and that player only, no matter what the player says it can handle. I thought that I could create a custom-convert.conf rule for that player that tells it to transcode ALAC to FLAC, hence the rule I reference above.

AFAIK unless you disable alac native globally, it's difficult. I'll try to explain a bit how it works.

LMS sees that source is "alc". It then reads the list of codecs the player is supporting which is "alc,aac,ogg,ops,ogf,flc,aif,pcm,mp3" for squeezelite-esp32 (unless PolyVection has changed it) and then starts rules matching.

So it the rule matcher will look for and "alc xxx" rule where xxx is in the list of codecs, using the order sent by player (unless the "prefer native codec" option is checked, in which case the rule matcher will *always* start with the source code).

So it starts with any rule "alc alc" and it will start first with custom-convert rules and rules that specify a player model or mac address, that's true. But in your case, it finds and "alc alc" rule (which is the identity rule) that matches and because that rule is not disabled, this is the end of the search. The rule also have criteria if you want to seek, resample, or that apply to different source (Remote, stdIn, File), but that's irrelevant in your case.

So, if you want a different outcome, you can use one of these options

- disable alc native support for all players
- remove alc from codecs supported by DAC32
- change order of codecs reported by DAC32 (needs recompile)
- build an "alc alc" rule for your DAC32 (specifiy MAC) that forces resample to 48kHz (e.g.)

But simply doing an 'alc flc' rule will not do anything because the 'alc alc' general rule will work and prevail

[benh]

AFAIK unless you disable alac native globally, it's difficult. I'll try to explain a bit how it works.

LMS sees that source is "alc". It then reads the list of codecs the player is supporting which is "alc,aac,ogg,ops,ogf,flc,aif,pcm,mp3" for squeezelite-esp32 (unless PolyVection has changed it) and then starts rules matching.

So it the rule matcher will look for and "alc xxx" rule where xxx is in the list of codecs, using the order sent by player (unless the "prefer native codec" option is checked, in which case the rule matcher will *always* start with the source code).

So it starts with any rule "alc alc" and it will start first with custom-convert rules and rules that specify a player model or mac address, that's true. But in your case, it finds and "alc alc" rule (which is the identity rule) that matches and because that rule is not disabled, this is the end of the search. The rule also have criteria if you want to seek, resample, or that apply to different source (Remote, stdIn, File), but that's irrelevant in your case.

So, if you want a different outcome, you can use one of these options

- disable alc native support for all players
- remove alc from codecs supported by DAC32
- change order of codecs reported by DAC32 (needs recompile)
- build an "alc alc" rule for your DAC32 (specifiy MAC) that forces resample to 48kHz (e.g.)

But simply doing an 'alc flc' rule will not do anything because the 'alc alc' general rule will work and prevail

Thank you. I think I understand more now.

To restate what you said, the order of operations is to match rules based on:

1. source codec plus player supported codecs, in the order given by the player
2. It finds first match of source and supported codec and executes, rather than finding most specific match, with the following caveats:
3. If there is more than one rule matching the source codec plus supported codec, the rule matcher will then inspect player model and MAC address values
4. If "Prefer native format (decoding on the player) whenever possible" is enabled, it will ignore all of the above and just send source codec natively, assuming the source codec matches any supported player codec. If there is not a native match, it will begin to inspect the rules.

In my use case, if I create an alc alc rule in custom-convert.conf, it will match that rule first, and stop. It didn't match the alc flc rule because it was looking for an alc alc rule due to alc being the native codec, and alc coming before flc in the supported codec assertion from the player.

I have tested and confirmed that an alc alc rule in custom-convert.conf matches. Haven't figured out the syntax to resample alc yet, as per your suggestion above.

So, I think that I could disable native alc alc support globally, write a rule to transcode alc to flc for the DAC32, and then write another rule that matches alc alc as a fall through for every other player. The net effect would be to support native alc codec everywhere but the DAC32. Let me test that...

Hm. I got the first part of that to work, but now ALL alc is being transcoded to flc. Have to work on that a bit more.

Again, very helpful. Thanks.