Handle Single File Album (with .cue file) #355

Author

Owner

@YodaSpow commented on GitHub (Sep 27, 2019):

Can this script for shnsplit or something similar be added to avoid the manual command line as part of a post-process, to avoid single FLAC files with cue being parked in Wanted?

Automatically split single file albums via .CUE file:
https://feathub.com/lidarr/Lidarr/+50

@YodaSpow commented on GitHub (Sep 27, 2019): Can this script for `shnsplit` or something similar be added to avoid the manual command line as part of a post-process, to avoid single FLAC files with cue being parked in Wanted? Automatically split single file albums via .CUE file: [https://feathub.com/lidarr/Lidarr/+50](https://feathub.com/lidarr/Lidarr/+50)

deekerman commented

Author

Owner

@ChaosBlades commented on GitHub (Sep 27, 2019):

Not sure exactly the script https://github.com/rembo10/headphones uses but they do this. When it finds a .cue file during post processing it runs a shnsplit script then processes the files it outputs.

@ChaosBlades commented on GitHub (Sep 27, 2019): Not sure exactly the script https://github.com/rembo10/headphones uses but they do this. When it finds a .cue file during post processing it runs a shnsplit script then processes the files it outputs.

deekerman commented

Author

Owner

@vKnmnn commented on GitHub (Oct 1, 2019):

There's this script (Post # 10) an arch-user wrote to split single-file-albums, which could probably be reused for this purpose.
could a dev maybe point into a direction where one could start looking at to implement this?

@vKnmnn commented on GitHub (Oct 1, 2019): There's this [script](https://bbs.archlinux.org/viewtopic.php?id=75774) (Post # 10) an arch-user wrote to split single-file-albums, which could probably be reused for this purpose. could a dev maybe point into a direction where one could start looking at to implement this?

deekerman commented

Author

Owner

@GaroRobe commented on GitHub (Oct 1, 2019):

A note: it doesn't always work. I don't get why actually, but sometimes it fails. Still succeeds in like 9 out of 10 cases for me, which is reasonably good for me.

@GaroRobe commented on GitHub (Oct 1, 2019): A note: it doesn't always work. I don't get why actually, but sometimes it fails. Still succeeds in like 9 out of 10 cases for me, which is reasonably good for me.

deekerman commented

Author

Owner

@mabushey commented on GitHub (Oct 7, 2019):

FLAC/APE+CUE albums are good (as gapeless experience?) and all, but quite impractical, because:

I find single file FLAC+CUE to be quite practical. My approach is to use CueTools to merge multiple track albums into single file FLAC's. A lot of utilities like Beets or as you say Plex doesn't work. That's OK with me. Plenty of players work fine.

@mabushey commented on GitHub (Oct 7, 2019): > FLAC/APE+CUE albums are good (as gapeless experience?) and all, but quite impractical, because: I find single file FLAC+CUE to be quite practical. My approach is to use CueTools to merge multiple track albums into single file FLAC's. A lot of utilities like Beets or as you say Plex doesn't work. That's OK with me. Plenty of players work fine.

deekerman commented

Author

Owner

@GaroRobe commented on GitHub (Oct 9, 2019):

e FLAC+CUE to be quite practical. My approach is to use CueTools to merge multiple track albums into single file FLAC's. A lot of utilities like Beets or as you say Plex doesn't work. That's OK with me. Plenty of players work fine.

Well, since I specifically use (whatever)arrs for managing home media server, not having a proper way to stream media looks like missing the whole point of installing them in the first place. Managing one personal playlist is not that difficult even manually.

@GaroRobe commented on GitHub (Oct 9, 2019): > e FLAC+CUE to be quite practical. My approach is to use CueTools to merge multiple track albums into single file FLAC's. A lot of utilities like Beets or as you say Plex doesn't work. That's OK with me. Plenty of players work fine. Well, since I specifically use (whatever)arrs for managing home media server, not having a proper way to stream media looks like missing the whole point of installing them in the first place. Managing one personal playlist is not that difficult even manually.

deekerman commented

Author

Owner

@cjmanca commented on GitHub (Jun 14, 2020):

Could we maybe get an option to split them into separate files automatically though for those of us who would like them separated? A good portion of the things that are being grabbed are in this flac/cue single file format, and I need to split each manually and then manually import. At that point, lidarr isn't really doing it's job anymore.

@cjmanca commented on GitHub (Jun 14, 2020): Could we maybe get an option to split them into separate files automatically though for those of us who would like them separated? A good portion of the things that are being grabbed are in this flac/cue single file format, and I need to split each manually and then manually import. At that point, lidarr isn't really doing it's job anymore.

deekerman commented

Author

Owner

@hughesjs commented on GitHub (Jun 17, 2020):

Is there any reason why we can't just run cuebreakpoints *.cue | shnsplit -o flac *.flac; cuetag *.cue split-*.flac every time we get a single-file flac download with a cue? That should split the track and tag them up so lidarr knows whats what to import it.

@hughesjs commented on GitHub (Jun 17, 2020): Is there any reason why we can't just run `cuebreakpoints *.cue | shnsplit -o flac *.flac; cuetag *.cue split-*.flac` every time we get a single-file flac download with a cue? That should split the track and tag them up so lidarr knows whats what to import it.

deekerman commented

Author

Owner

@ta264 commented on GitHub (Jun 17, 2020):

PRs welcome :)

@ta264 commented on GitHub (Jun 17, 2020): PRs welcome :)

deekerman commented

Author

Owner

@vKnmnn commented on GitHub (Jun 17, 2020):

What's the point of having a ranked list of feature requests when you can just deflect any issue by saying PR welcome?

I get it, nobody is paying you and you guys are developing this in your own free time.

@vKnmnn commented on GitHub (Jun 17, 2020): What's the point of having a ranked list of feature requests when you can just deflect any issue by saying PR welcome? I get it, nobody is paying you and you guys are developing this in your own free time.

deekerman commented

Author

Owner

@fapnip commented on GitHub (Feb 1, 2021):

Any way we could get "Priority: low" pulled from this?

A good number of downloaded FLAC albums are needing this.

@fapnip commented on GitHub (Feb 1, 2021): Any way we could get "Priority: low" pulled from this? A good number of downloaded FLAC albums are needing this.

deekerman commented

2026-02-20 01:01:14 -05:00

Author

Owner

@tyestor commented on GitHub (Nov 8, 2021):

I get it, nobody is paying you and you guys are developing this in your own free time.

actually they are being paid: https://opencollective.com/lidarr

@tyestor commented on GitHub (Nov 8, 2021): > I get it, nobody is paying you and you guys are developing this in your own free time. actually they are being paid: https://opencollective.com/lidarr

deekerman commented

Author

Owner

@RobinDadswell commented on GitHub (Nov 8, 2021):

actually they are being paid: https://opencollective.com/lidarr

None of those donations come to any of the developers and is spent on the infrastructure that supports things like the metadata server and the update server etc..

@RobinDadswell commented on GitHub (Nov 8, 2021): > actually they are being paid: https://opencollective.com/lidarr None of those donations come to any of the developers and is spent on the infrastructure that supports things like the metadata server and the update server etc..

deekerman commented

2026-02-20 01:01:14 -05:00

Author

Owner

@ChaosBlades commented on GitHub (Nov 28, 2021):

I just opened the flood gates to allow Lidarr to upgrade albums to FLAC... pulling over 300 of these single file albums. Looks like I'll be busy the next several hours.
We could use Flacon to split these. It supports WAV, FLAC, APE, WavPack, True Audio (TTA)
https://github.com/flacon/flacon/wiki/Command-line-usage

@ChaosBlades commented on GitHub (Nov 28, 2021): I just opened the flood gates to allow Lidarr to upgrade albums to FLAC... pulling over 300 of these single file albums. Looks like I'll be busy the next several hours. We could use Flacon to split these. It supports WAV, FLAC, APE, WavPack, True Audio (TTA) https://github.com/flacon/flacon/wiki/Command-line-usage

deekerman commented

2026-02-20 01:01:14 -05:00

Author

Owner

@GordonFreemanK commented on GitHub (Dec 22, 2021):

I would like to chip in if I may. In the world of trackers, the flac + cue format is pretty much the first choice, so splitting the album makes you have to maintain two copies (one for seeding one for the library).

To mitigate the issue with Plex and other incompatible software, you could use TrackFS. This project uses FUSE to create a virtual filesystem identical to your music library, but with all full files divided into tracks... This is a virtual (read-only) filesystem, so it doesn't take space or modify the files, instead it takes CPU at the moment you are reading those files. Obviously not meant for mass copy, but should work for streaming audio, the idea being that you use this read-only virtual FS as the library for Plex.

All this is missing is the capacity for Lidarr to handle this. Weirdly though what this thread seems to omit is that Lidarr does handle them pretty well at the moment: when importing your full album you can multi-select tracks (so you'd select all the tracks for this single file). The only issue for me is that when renaming the file, Lidarr actually includes every single track number and name. I think the only thing missing is a way to tell Lidarr that for renaming multi-track files, it should omit individual track names and fall back onto the album name. Does this make sense?

@GordonFreemanK commented on GitHub (Dec 22, 2021): I would like to chip in if I may. In the world of trackers, the flac + cue format is pretty much the first choice, so splitting the album makes you have to maintain two copies (one for seeding one for the library). To mitigate the issue with Plex and other incompatible software, you could use [TrackFS](https://github.com/andresch/trackfs). This project uses FUSE to create a virtual filesystem identical to your music library, but with all full files divided into tracks... This is a virtual (read-only) filesystem, so it doesn't take space or modify the files, instead it takes CPU at the moment you are reading those files. Obviously not meant for mass copy, but should work for streaming audio, the idea being that you use this read-only virtual FS as the library for Plex. All this is missing is the capacity for Lidarr to handle this. Weirdly though what this thread seems to omit is that Lidarr does handle them pretty well at the moment: when importing your full album you can multi-select tracks (so you'd select all the tracks for this single file). The only issue for me is that when renaming the file, Lidarr actually includes every single track number and name. I think the only thing missing is a way to tell Lidarr that for renaming multi-track files, it should omit individual track names and fall back onto the album name. Does this make sense?

deekerman commented

Author

Owner

@GaroRobe commented on GitHub (Dec 22, 2021):

I would like to chip in if I may. In the world of trackers, the flac + cue format is pretty much the first choice, so splitting the album makes you have to maintain two copies (one for seeding one for the library).

To mitigate the issue with Plex and other incompatible software, you could use TrackFS. This project uses FUSE to create a virtual filesystem identical to your music library, but with all full files divided into tracks... This is a virtual (read-only) filesystem, so it doesn't take space or modify the files, instead it takes CPU at the moment you are reading those files. Obviously not meant for mass copy, but should work for streaming audio, the idea being that you use this read-only virtual FS as the library for Plex.

All this is missing is the capacity for Lidarr to handle this. Weirdly though what this thread seems to omit is that Lidarr does handle them pretty well at the moment: when importing your full album you can multi-select tracks (so you'd select all the tracks for this single file). The only issue for me is that when renaming the file, Lidarr actually includes every single track number and name. I think the only thing missing is a way to tell Lidarr that for renaming multi-track files, it should omit individual track names and fall back onto the album name. Does this make sense?

Um... No, it doesn't?

It's not a portable solution. And even on Linux is just a way to shift a problem from "file packing issue" to "administration issue". And second one is much, MUCH more difficult either to set up and to maintain. If I'd wanted to be "super-Linux-way" I'd just cron something to split media. I actually did that manually until got fed up with all that labor - it's easier to search split albums manually and that's what I do. Even though it kinda defeats all the purpose

Maybe my expectations are just beyond what's considered "normal", but I consider Lidarr "a product" - and if there is a very frequent case in product's scope, just saying "it's a non-issue" IMO is a bit wrong.

@GaroRobe commented on GitHub (Dec 22, 2021): > I would like to chip in if I may. In the world of trackers, the flac + cue format is pretty much the first choice, so splitting the album makes you have to maintain two copies (one for seeding one for the library). > > To mitigate the issue with Plex and other incompatible software, you could use [TrackFS](https://github.com/andresch/trackfs). This project uses FUSE to create a virtual filesystem identical to your music library, but with all full files divided into tracks... This is a virtual (read-only) filesystem, so it doesn't take space or modify the files, instead it takes CPU at the moment you are reading those files. Obviously not meant for mass copy, but should work for streaming audio, the idea being that you use this read-only virtual FS as the library for Plex. > > All this is missing is the capacity for Lidarr to handle this. Weirdly though what this thread seems to omit is that Lidarr does handle them pretty well at the moment: when importing your full album you can multi-select tracks (so you'd select all the tracks for this single file). The only issue for me is that when renaming the file, Lidarr actually includes every single track number and name. I think the only thing missing is a way to tell Lidarr that for renaming multi-track files, it should omit individual track names and fall back onto the album name. Does this make sense? Um... No, it doesn't? It's not a portable solution. And even on Linux is just a way to shift a problem from "file packing issue" to "administration issue". And second one is much, MUCH more difficult either to set up and to maintain. If I'd wanted to be "super-Linux-way" I'd just cron something to split media. I actually did that manually until got fed up with all that labor - it's easier to search split albums manually and that's what I do. Even though it kinda defeats all the purpose Maybe my expectations are just beyond what's considered "normal", but I consider Lidarr "a product" - and if there is a very frequent case in product's scope, just saying "it's a non-issue" IMO is a bit wrong.

deekerman commented

Author

Owner

@GordonFreemanK commented on GitHub (Dec 22, 2021):

I don't know if you meant me but I really didn't say yours is a non-issue. To be fair, we're downloading files that are incompatible with our media player and asking Lidarr devs to fix it for us... The most sensible solution would definitely be to either restrict to files that are compatible with the player (which you're doing) or get our media player of choice to support them.

Splitting a file isn't trivial, it requires re-encoding (except for mp3s if you split with mp3split) which means that in order to distribute a fully fledge splitting feature Lidarr would have to embed the tools to split and transcode , for all supported audio formats and platorms, while minding distribution licenses (e.g. APE isn't open source so it's probably impossible to distribute).

Personnally I think your workflow for splitting would be best served by a generic feature to trigger custom scripts on import in Lidarr, and my workflow (forgetting about FUSE) would be best served by Lidarr having a different naming scheme for single file albums and some form of support for cue files to read track lengths. They aren't incompatible workflows, just different ones.

@GordonFreemanK commented on GitHub (Dec 22, 2021): I don't know if you meant me but I really didn't say yours is a non-issue. To be fair, we're downloading files that are incompatible with our media player and asking Lidarr devs to fix it for us... The most sensible solution would definitely be to either restrict to files that are compatible with the player (which you're doing) or [get our media player of choice to support them](https://forums.plex.tv/t/flac-files-with-cue/9966/230). Splitting a file isn't trivial, it requires re-encoding (except for mp3s if you split with mp3split) which means that in order to distribute a fully fledge splitting feature Lidarr would have to embed the tools to split **and** transcode , _for all supported audio formats and platorms_, while minding distribution licenses (e.g. APE isn't open source so it's probably impossible to distribute). Personnally I think your workflow for splitting would be best served by a generic feature to trigger custom scripts on import in Lidarr, and my workflow (forgetting about FUSE) would be best served by Lidarr having a different naming scheme for single file albums and some form of support for cue files to read track lengths. They aren't incompatible workflows, just different ones.

deekerman commented

Author

Owner

@cjmanca commented on GitHub (Jan 27, 2022):

in order to distribute a fully fledge splitting feature Lidarr would have to embed the tools to split and transcode , for all supported audio formats and platorms, while minding distribution licenses (e.g. APE isn't open source so it's probably impossible to distribute).

I think most people would be fine with having to install transcoding tools themselves in order for the feature to work. No need to bundle them in lidarr. If you don't have the transcoding tools installed, then lidarr can just do nothing (which is what it already does anyway).

@cjmanca commented on GitHub (Jan 27, 2022): > in order to distribute a fully fledge splitting feature Lidarr would have to embed the tools to split **and** transcode , _for all supported audio formats and platorms_, while minding distribution licenses (e.g. APE isn't open source so it's probably impossible to distribute). I think most people would be fine with having to install transcoding tools themselves in order for the feature to work. No need to bundle them in lidarr. If you don't have the transcoding tools installed, then lidarr can just do nothing (which is what it already does anyway).

deekerman commented

Author

Owner

@fapnip commented on GitHub (Jan 27, 2022):

Splitting a file isn't trivial, it requires re-encoding (except for mp3s if you split with mp3split) which means that in order to distribute a fully fledge splitting feature Lidarr would have to embed the tools to split and transcode , for all supported audio formats and platorms, while minding distribution licenses

I assume most of us would have no problem pointing Lidarr to where FFMPEG is installed -- and FFMPEG probably will handle most of what's needed for this feature -- which is, if we're being honest, just FLAC.

@fapnip commented on GitHub (Jan 27, 2022): > Splitting a file isn't trivial, it requires re-encoding (except for mp3s if you split with mp3split) which means that in order to distribute a fully fledge splitting feature Lidarr would have to embed the tools to split **and** transcode , _for all supported audio formats and platorms_, while minding distribution licenses I assume most of us would have no problem pointing Lidarr to where FFMPEG is installed -- and FFMPEG probably will handle most of what's needed for this feature -- which is, if we're being honest, just FLAC.

deekerman commented

Author

Owner

@hughesjs commented on GitHub (Feb 3, 2022):

You literally just need shntool... It's not exactly a big dependency considering we have mono as one... It's also GPL-2.0 so we could easily redistribute it if you didn't want to just have it as an external dependency

@hughesjs commented on GitHub (Feb 3, 2022): You literally just need `shntool`... It's not exactly a big dependency considering we have mono as one... It's also GPL-2.0 so we could easily redistribute it if you didn't want to just have it as an external dependency

deekerman commented

Author

Owner

@bakerboy448 commented on GitHub (Feb 3, 2022):

Mono is no longer supported with v1

I'm sure if it was that easy is would have been done so already.

If you believe it's that easy - well PRs welcome

@bakerboy448 commented on GitHub (Feb 3, 2022): Mono is no longer supported with v1 I'm sure if it was that easy is would have been done so already. If you believe it's that easy - well PRs welcome

deekerman commented

Author

Owner

@hughesjs commented on GitHub (Feb 3, 2022):

Is the project .net core now then? Admittedly, I've not looked at the source for a while...

Unfortunately, I barely have enough time for my job and PhD research so finding time to contribute to new projects is difficult... But if nobody gets round to it before me I'll take a look... Really shouldn't be difficult

@hughesjs commented on GitHub (Feb 3, 2022): Is the project .net core now then? Admittedly, I've not looked at the source for a while... Unfortunately, I barely have enough time for my job and PhD research so finding time to contribute to new projects is difficult... But if nobody gets round to it before me I'll take a look... Really shouldn't be difficult

deekerman commented

Author

Owner

@hughesjs commented on GitHub (Feb 3, 2022):

Oooh .NET 6... That's a nice surprise

@hughesjs commented on GitHub (Feb 3, 2022): Oooh .NET 6... That's a nice surprise

deekerman commented

Author

Owner

@reijerh commented on GitHub (Mar 10, 2023):

Just gonna leave this oneliner here, it looks for all folders in a give path that contain only 1 file with the given file extension (recursively), and then calls unflac on it with a given output path in which all split files will be placed (in a subtree).

You can pass a date since when you want to search.

find /home/XXX/Downloads/ -newermt 2023-03-03 -name '*.flac' -printf '%h\n' | sort | uniq -c | while read -r n d ; do [ $n -lt 2 ] && go/bin/unflac -o ~/flacs "$d" 2>&1 ; done

You can run this occasionally by hand or automatically. Something like this would be decent for Lidarr imo, or just the option to execute a script post-download/pre-import.

(shnsplit is currently kind of broken on Debian, it can't handle certain high bitrate files, there's a patch waiting for this but the maintainer seems to have ignored it for years)

@reijerh commented on GitHub (Mar 10, 2023): Just gonna leave this oneliner here, it looks for all folders in a give path that contain only 1 file with the given file extension (recursively), and then calls `unflac` on it with a given output path in which all split files will be placed (in a subtree). You can pass a date since when you want to search. `find /home/XXX/Downloads/ -newermt 2023-03-03 -name '*.flac' -printf '%h\n' | sort | uniq -c | while read -r n d ; do [ $n -lt 2 ] && go/bin/unflac -o ~/flacs "$d" 2>&1 ; done` You can run this occasionally by hand or automatically. Something like this would be decent for Lidarr imo, or just the option to execute a script post-download/pre-import. (`shnsplit` is currently kind of broken on Debian, it can't handle certain high bitrate files, there's a patch waiting for this but the maintainer seems to have ignored it for years)

deekerman commented

Author

Owner

@hughesjs commented on GitHub (Mar 10, 2023):

The QR for my PhD is due soon and the pressure will be off for a bit after that, so I might finally have some time to look at this

@hughesjs commented on GitHub (Mar 10, 2023): The QR for my PhD is due soon and the pressure will be off for a bit after that, so I might finally have some time to look at this

deekerman commented

Author

Owner

@zhangdoa commented on GitHub (Oct 12, 2023):

Hello, is there any progresses here? I have a working fork for single file album support for my own usage, and if it's doable, I would consider sending a PR for it after getting more required test code in.

@zhangdoa commented on GitHub (Oct 12, 2023): Hello, is there any progresses here? I have a working fork for single file album support for my own usage, and if it's doable, I would consider sending a PR for it after getting more required test code in.

deekerman commented