Activity for scrutinizer
-
scrutinizer created ticket #623
XLD CLI: GENRE, ARTIST, COMMENT and OTHER TAGS not added
-
I've changed my mind: you may disregard the bit about processing separate audio-files by reading the cue sheet. Upon revising the code, it turned out that I had foreseen such a situation. Nevertheless, batch-converting remains as an enhancement request. Thank you for you job!
-
Please Add The Option Of Batch-Converting On The Command Line
-
This time, I managed to encode a true AIFF PCM media to FLAC. The question is why is it compressing the original more than expected (91% vs 86%)? The command output says level 5 compression is applied. What is level 5 and how do I look up and set the levels? I attach the comparison record.
-
Input file is ALAC (.m4a). Output file - any supported audio file format from mp3 to AIFF and WAV. The command just like I posted in my OP. It fails even without any option. The input file is an audio screen recording. Attaching the metadata analysis.
-
Which is the arch I'm running on. The issue affects XLD in every macOS version from 10.7 to 10.14. RIght now, it's 10.9. It errors out with every format, every option and I tried every combo. I hear about some plugins in need of installation the first time ever. As I said, it worked before 2021. I need x86-64. Is it even available?
-
Which is the arch I'm running on. The issue affects XLD with every macOS version from 10.7 to 10.14. RIght now, it's 10.9. It errors out with every format, every option and I tried every combo. I hear about some plugins in need of installation the first time ever. As I said, it worked before 2021. I need x86-64. Is it even available?
-
Which is the arch I'm running on. The issue affects XLD with every macOS version from 10.7 to 10.14. RIght now, it's 10.9. It errors out with every format, every option and I tried every combo. I hear about some plugins in need of installation the first time ever. As I said, it worked before 2021.
-
XLD CLI error: cannot handle file
-
I second you. I get exactly the same error. XLD 20211018, macOS Mojave and happens while using the CLI version in my AppleScript scipt inside Automator. The command assembly is do shell script "/usr/local/bin/xld -f " & Codec & " -o " & (quoted form of "$HOME/Music/iTunes/iTunes Media/Automatically Add to iTunes.localized/") & space & Profile & space & audfilepath where Profile is --profile plus the profile's name as per the xld's manual, Codec is aif and audfilepath is a quoted Posix path. Either...
-
Add the bit setting option to the command line version for non-RAW files
-
Thank you for your help, I managed to install and make it run. However, the next main problem is that the CLI falters when there’s 1 cue sheet and several target files referenced in the sheet. It halts at the track with the highest index corresponding to the last track of the first original file and throws the following error (in this case, 9 tracks of 23 defined in the cue were transcoded before the fault). (Track 8/23)/usr/local/bin/xld: line 11: 9336 Segmentation fault: 11 "${XLD_APP}/Contents/MacOS/XLD"...
-
I went with the CLI/xld approach, changed the extension to sh, edited appropriate lines, removed the extension, tried to run, however bash complaints that the command not found. I extracted xld with Pacifist to Documents. Do I have to put it in /usr/local/bin?
-
CLI version of XLD stuck on doing nothing
-
CLI: add basic file analysis options, convert-to-alac option
-
Won't accept multiple CUE sheets for batch processing.
-
Hello, I'm facing the exact same problem on Mavericks and Lion. XLD 20181019. I also noticed that on this site the offered version as the current release (the green download button) is 20181019, although the real current version is 20191004 found in the changelog section. But even in this version the same update error pops up. Perhaps that's related to the aforementioned mistake with deploying versions on this site.
-
Hello, I'm facing the exact same problem on Mavericks and Lion. XLD 20181019. I also noticed that on this site the offered version as the current release (the green download button) is 20181019, although the real current version is 20191004 found in the changelog section. But even in this version the same update error pops up. Perhaps that's related to the aforementioned mistake with deploying versions on this site.
-
Hello, I'm facing the exact same problem on Mavericks and Lion. XLD 20181019
-
Hello, I'm facing the exact same problem on Mavericks. XLD 20181019
-
Oh, thank you. A user error.
-
Since I placed the links with improper formatting I'm re-posting them: Link #1 https://1drv.ms/u/s!Ar7_8hidDIZziFJb21WjjVc2fA3x Link #2 https://d.docs.live.net/73860c9d18f2ffbe/Documents/XLD.mov
-
Alien characters - not possible to set right
-
Umm okay, I understand. (BTW I know they "won't retroactively support my system" as much as I know that upgrades are not supported for every Mac computer). Well, that means that, whatever it might be, and despite the stated system requirements, I'm left with other option than to resolve this software conflict in favor of my system since the full-screen benefits are much required in my working envorinment. My only suggestion for you would be to elevate mininal system requirements to the minimal version...
-
Umm okay, I understand. (BTW I know they "won't retroactively support my system" as much as I know that upgrades are not supported for every Mac computer). Well, that means that, whatever it might be, and despite the stated system requirements, I'm left with other option than to resolve this software conflict in favor of my system since the full-screen benefits are much required in my working envorinment. My only suggestion for you would be to elevate mininal system requirements up to the version...
-
Umm okay, I understand. (BTW I know they "won't retroactively support my system" as much as I know that upgrades are not supported for every Mac computer). Well, that means that, whatever it might be, and despite the stated system requirements, I'm left with other option than to resolve this software conflict in favor of my system since the full-screen benefits are much required in my working envorinment. Thank you for your replies.
-
Check out a video-capture of the UI elements movement in Preview I made http://vimeo.com/282065301
-
I ran these commands with Skim quit. Moreover, since that's not the issue with Preview I can only assume that the values for these sidebars are not calculated properly (if they are at runtime and weren't hard-coded by the developers) or, in either way, fail to establish correct settings in a full screen mode because even with the title bar hidden the sidebars extend over the visible area along the height of the screen instead of incrementing proportionally to adjust to the screens with 1400 x 900...
-
I ran these commands with Skim quit. Moreover, since that's not an issue with Preview I can only assume that the values for these sidebars are not being calculated properly (if they are at runtime and weren't hard-coded by the developers) or, in either way, fail to establish correct settings in a full screen mode because even with the title bar hidden the sidebars extend over the visible area along the height of the screen instead of incrementing proportionally to adjust to the screens with 1400...
-
That's when the cursor does not touch the top of the screen Update. Upon re-launch the issue returned.
-
I think I discovered something that I cannot find a credible explanation of with this hidden setting. I accidentally ran the full screen command without SKAutoHideToolbarInFullScreen key as defaults write net.sourceforge.skim-app.skim -boolean yes And I got the expected behaviour. When I noticed my mistake I immediately executed the command with the key added: it enabled auto-hide but left the fields half-covered by the top of the screen. I then omitted the key again and it ended up with what I initially...
-
That's when the cursor does not touch the top of the screen
-
I think I discovered something that I cannot find a credible explanation of with this hidden setting. I accidentally ran the full screen command without SKAutoHideToolbarInFullScreen key as defaults write net.sourceforge.skim-app.skim -boolean yes And I got that behaviour. When I noticed my mistake I immediately executed the command with the key added: it enable auto-hide but left the fields hal-covered by the toop of the screen. I then omitted the key again and it ended up with what I initially...
-
I think only you can fix this by upgrading your buggy system "or uninstall Skim" :)
-
A full screen mode of the same view:
-
Oops. I replied in a message but that seems not implemented with this forum. My system is Lion. Here how it looks in standard view
-
Search fields on the both sided are covered by Title bar in a full-screen mode
1
