INTERACT FORUM
Windows => Third Party Plug-ins, Programs, and Skins => Topic started by: scthom on August 13, 2005, 03:42:17 am
-
A new version of the FLAC Encoder Plugin is now available. In addition, a new version of the FLAC Input (Decoder) Plugin is also now available.
Encoder is now version 1.3
Decoder is version 1.0
See my homepage for the files - http://members.cox.net/scot.thompson/ (http://members.cox.net/scot.thompson/).
[Edit by JimH:]
Note that FLAC support is now native to MC12 and MC13 -- no need to download plug-ins
I'll get them posted to the plugin download page here on Interact pretty soon.
-
Great! Excellent work again.
My notes:
CueSheets are not (yet) implemented. I haven't tried and can't say when it might be done.
Yes, I can see they don't work. When trying to play CUE tracks (using a separate .cue file) only the first track can be played in MC . MC collects the track info correctly including the playback range values, but something else does not work. I wasn't aware that this is depended on the type of the input plug-in implementation. When JRiver introduced the cue sheet playback support they didn't update all input plug-ins at the same time. CUE tracks work with all other formats I have tried (APE, MP3, MPC, WMA, OGG).
Not sure exactly why, but Oblong's plugin reported various bitrates. The real bitrate is 1411 kb/s (2 channels * 44100 samples per second * 16 bits per sample) for most files. That's what I report.
I think you are making a mistake here. All input plug-ins should show the compressed bitrate (variable if the format is VBR). Showing the decoded bitrate is not the intended purpose of the bitrate display in MC. Otherwise MC should display 1411 also when e.g. MP3 files are played. Showing the compressed bitrate gives some useful information about the file. You can try this with APE files.
-
SC, you are a busy fellow! I'm trying out your (encoder) plugin right now, and it seems fine. Thank you!
One comment. I went to the FLAC page at sourceforge, and they say the default quality setting is -5, FWIW.
http://flac.sourceforge.net/documentation.html
-
More on the -5 vs -6 issue. -6 (the setting in your ver 1.3) is better. I don't notice the increased process time, but all of a sudden the encoder can find some whopping compression improvements. Most are roughly similar but a few are SIGNIFICANTLY smaller, as if the encoder is all of a sudden using one more algorithm pass that occassionally really hits the mark.
-
Yet still more input.
There may be an issue with the reported bitrate in the encoder. Having run through a good number of conversions, I found one that started out as 1411 and ended up as 1450.
I took it to the editor, decoded and saved it off as WAV, and examined it and its evil twin in win explorer. I then imported the wav and recoded it, and it ended up at the exact same file size, ~40% of original, and reported the same 1450 kbps falsehood.
-
More and more. The duration shown is wrong, too short seemingly be the inverse of the ratio that bitrate is over-reported. MC will not play the track past its reported duration, it skips to the next track. However, Media Editor, which looks at the decoded WAV, plays it and shows it just fine.
-
Sorry, SC, this is broken. Out of 40 files converted, 3 are bad. 1 reports bitrate too high, the other 2 too low. Resulting file is unplayable within MC. I'm going back to your previous rev. I appreciate your hard work and I'm sure a minor tweak will get the show back on the road. Thanks again.
-
Further update. All files are bad. None will obey manual clicking ahead in the progress bar, they simply cut to the next track.
Sorry, scthom, it looked good at the start. I've gone back to your version 1.2001 and it continues to work just fine.
-
I think you are making a mistake here. All input plug-ins should show the compressed bitrate (variable if the format is VBR). Showing the decoded bitrate is not the intended purpose of the bitrate display in MC. Otherwise MC should display 1411 also when e.g. MP3 files are played. Showing the compressed bitrate gives some useful information about the file. You can try this with APE files.
The thing is, from browsing Oblong's original plugin, he was doing the same calculation I am. At least as near as I could tell. He was just getting different results (integer math error perhaps). The thing is, we really are sampling at 1411 kb/s (44100 samples per second). MP3's using e.g. 256 kb/s are reducing the sample rate, hence the loss in the format. Our reduction in file size comes from the ability to compress the encoded samples, not from reduced sampling. It wasn't clear from the SDK what was expected and for their simple WAV example, it didn't matter.
One comment. I went to the FLAC page at sourceforge, and they say the default quality setting is -5, FWIW.
Maybe that's where I saw it. However, the flac.exe help says it defaults to -6.
More and more. The duration shown is wrong, too short seemingly be the inverse of the ratio that bitrate is over-reported. MC will not play the track past its reported duration, it skips to the next track. However, Media Editor, which looks at the decoded WAV, plays it and shows it just fine.
Perhaps you can send me one of the files in question. I tested it on my own library and did not find anything that didn't work. But it's hard to test all the variety of possible errors :)
Further update. All files are bad. None will obey manual clicking ahead in the progress bar, they simply cut to the next track.
Sorry, scthom, it looked good at the start. I've gone back to your version 1.2001 and it continues to work just fine.
Just to be clear, the encoder version (1.3) is probably not the issue, for these types of errors, it's the decoder (1.0).
-
Scthom--
Sorry to be such a pain on a Saturday morning. AFAIK, I downloaded your 1,3 ENcoder, uninstalled ver 1.2001, installed 1.3, and the issues began. I never downloaded the decoder, I continued to use Oblong's. Is that the issue?
-
Sorry to be such a pain on a Saturday morning. AFAIK, I downloaded your 1,3 ENcoder, uninstalled ver 1.2001, installed 1.3, and the issues began. I never downloaded the decoder, I continued to use Oblong's. Is that the issue?
No problem. I want it to work as much as you do ;D
The problems you describe are functions of the DECODER, not the ENCODER. I did make changes to both and it's possible something is amiss, but I would suspect the decoder first. The decoder is what returns all of the file information to MC. The changes to the encoder were pretty minor from the 1.2 version.
-
Don't I have to install the decoder to experience problems with it?
-
Don't I have to install the decoder to experience problems with it?
Well, one would think. It's possible that Oblong's decoder is not working properly with something in the files encoded by the new encoder. To be honest, I didn't try testing that.
See your Personal Messages. Send me an encoded file that has errors and I'll take a quick look-see.
-
The thing is, from browsing Oblong's original plugin, he was doing the same calculation I am. At least as near as I could tell. He was just getting different results (integer math error perhaps). The thing is, we really are sampling at 1411 kb/s (44100 samples per second). MP3's using e.g. 256 kb/s are reducing the sample rate, hence the loss in the format. Our reduction in file size comes from the ability to compress the encoded samples, not from reduced sampling. It wasn't clear from the SDK what was expected and for their simple WAV example, it didn't matter.
Did you check how APE files work? I guess Monkey's Audio is the reference lossless format in MC. Microsoft's WMA lossless decoder is not perfect. It shows only the average compressed bitrate (but not the decoded bitrate, which is always 1411 kbps if the source is CDA and the files are not resampled).
With audio files the term bitrate is normally used for expressing the compressed size in bits/playback time unit. 16 bit/44.1 kHz audio in FLAC format can have a bitrate from near zero up to 1411 kbps as explained here: http://flac.sourceforge.net/faq.html#general__lowest_bitrate
Matt could explain this better. I hope he will help you with this.
Anyway, this is not a biggie. Thanks a lot for your work!
-
Thanks again from me also, scthom. I emailed you with details on my unsuccessful attempt to get you a test track, so when you're ready on that end just let me know.
I've gotten a heck of a lot of mileage out of your v 1.2001 encoder, and I continue to use it, happily. Without your help I would be nowhere at this point. So take your time working through today's drama. I'll be happy to test out your latest efforts.
I personally have not seen any problems come up on the decoder side, FWIW.
-
Thank you, thank you, thank you. I love Monkey's, but all the hardware devices are FLAC. Now I can use those hardware decoders, and MC.
-
Did you check how APE files work? I guess Monkey's Audio is the reference lossless format in MC. Microsoft's WMA lossless decoder is not perfect. It shows only the average compressed bitrate (but not the decoded bitrate, which is always 1411 kbps if the source is CDA and the files are not resampled).
With audio files the term bitrate is normally used for expressing the compressed size in bits/playback time unit. 16 bit/44.1 kHz audio in FLAC format can have a bitrate from near zero up to 1411 kbps as explained here: http://flac.sourceforge.net/faq.html#general__lowest_bitrate
I guess part of the problem is that figuring out the encoded bitrate is not as easy as the decoded bitrate. The other part is I hadn't taken the time to fully understand what was expected. Further down the page on that FAQ is the key - http://flac.sourceforge.net/faq.html#api__frame_length
I can say it is fixed and will be released soon. I would like to fix whatever the problem with the encoder first.
One nice thing about writing these plugins is that I don't need to be an expert in audio encoding to make it work :)
-
Thanks to jgreen for finding the bug.
My encoder version 1.3 does have a small error between the end of the metadata and the first data frame. My decoder is set to skip errors, so it will play the files fine. Oblong's decoder is set to NOT skip errors, so it crashes.
The good news is you can recover the data from any corrupted file by using flac.exe (http://flac.sourceforge.net/download.html) with the "decode through errors" setting enabled (-F for the commandline version). This will decode to a wav, which you can then encode back using version 1.2 of my encoder (or flac.exe). Tags can be inserted using either Oblong's or my decoder plugin.
-
I just posted the updated versions on my website, http://members.cox.net/scot.thompson.
The encoder bug from 1.3 was fixed in 1.4, but the 1.5 adds the options to verify, skip the seektable block, and skip the comment block. The seektable block is set for 99 seekpoints, which will give you 1% resolution and adds less than 2k to the file. It makes seeking within the file a lot faster. The padding block you should never skip, and the decoder plugin(s) will add it if it's not there. Default size is 4k.
The decoder (ver 1.2) is updated with correct bitrate reporting, including VBR display. Also, you can select the option to "decode through errors", and the use of cue files is partially implemented. I say partially because MC doesn't handle them particularly well either. I import a cue file (same file name but *.cue) and import the cuesheet as a clear-text comment as well as into the cuesheet block. MC blocks saving tags from the library though. I don't find them particularly useful with MC at this point in time.
As always, these are USE AT YOUR OWN RISK. Let me know if you find any bugs or have feature implementation requests.
-
Looks cool, scthom. I installed the new encoder, wrangled a few .wav files, selected quality=6 and verify=on, and let fly. The tracks play well, and everything looks and sounds great. The speed didn't seem too much affected by the settings, including verfy. Shouldn't it be taking twice as long when I verify?
Feature request:
Every version you put out is named "Enc_FLAC.dll". Don't you ever crave variety, for example version numbers? Just a thought.
Great work again, scthom. I still haven't installed your DEcoder, but plan to soon. Any urgency re/ compatibility?
Very interesting development with CUE file support. I wish I knew how they worked.
-
Looks cool, scthom. I installed the new encoder, wrangled a few .wav files, selected quality=6 and verify=on, and let fly. The tracks play well, and everything looks and sounds great. The speed didn't seem too much affected by the settings, including verfy. Shouldn't it be taking twice as long when I verify?
Feature request:
Every version you put out is named "Enc_FLAC.dll". Don't you ever crave variety, for example version numbers? Just a thought.
Great work again, scthom. I still haven't installed your DEcoder, but plan to soon. Any urgency re/ compatibility?
Very interesting development with CUE file support. I wish I knew how they worked.
I would say no urgency on the decoder install. The advantage of Oblong's version is the storing of pictures. The advantage of mine is better support of the database tags, format display in File Type Info, decode through errors, and the marginal cue sheet support. I think there are some differences in very large files that his won't do as well at.
As to verify, not sure if it is theoretically twice as long. It's internal to the FLAC engine and to be honest, I'm not sure how they implement it. If they implented it by decoding and comparing, it's almost certainly not twice as slow since decoding is much faster than encoding. I would guess that adds around 15% (just a guess).
-
scthom,
I just wanted to say 'thank you'. Your hard work is very much appreciated.
-
using encoder 1.5 and decoder 1.2..
I'm having problems saving tag data to files Not images, just text, like bios and lyrics. MC chucks me that "make sure files are not read only or in use by something else" dialogue.
If I try an "update tags from library" on them, MC crashes (disappears on me).
Does the stuff in the File Type Info look right? Which blocks are found? Do you have existing tags? It almost sounds like the comment block isn't there. Are there any unusual characters in the text (e.g. accented characters, etc)? Is it a CUE file? I'll need a bit more info to diagnose.
FYI if you tried to save images, MC would let you set it, and the plugin does not complain, but it won't save to the file.
Typically this error is the result of the decoder, not the encoder. The decoder plugin is what handles all of the tagging. The encoder pretty much only does one thing, and that is make a plain vanilla file from a WAV.
-
I just tried this on a FLAC and it worked fine. I'm using your 1.5 encoder (although I don't know which version I used to encode that test FLAC). And I'm still using Oblong's original decoder. There was no cover art associated with the test FLAC.
-
Hokay, I think I might have it now:
Is there any size limit set on the way v1.2 saves the bios tag that oblong's version doesn't have?
What I'm seeing here is that oblong's will save an entire bios, which shows in the file type info window when I switch to v1.2, but v1.2 produces the "problems tagging... check they exist.. not read only" error when edited directly via tag info, and crashes MC when using update tags from library.
I was testing using a freshly ripped fleetwood mac track, and using aTagger to update the tags. I posted in the aTagger thread about an error it had been giving me recently, and I now think it's related to this problem.
-marko.
EDIT: (still with v1.2 installed)
Now I'm completely flumoxxed. After posting this, I removed the tags from that file, opened the bios tag and pasted in the entire fleetwood mac bios. It saved without error and shows in the tag info window. I select the next track in the album, this one has not been through aTagger, just a freshly ripped virgin track, paste the same bios in for that track and MC decides 'no can do'. Go back to the first track, open the bios, remove the full-stop from the end, save, MC says 'no can do'
Something isn't right. I'm pretty sure it's to do with the size of the bios tag. The first link below is the bios as pasted, the second is the dump from the file type info window.
http://www.theganghut.co.uk/files/bios.txt
http://www.theganghut.co.uk/files/ft-infodump.txt
I can't spend any more time on this unless there is something specific you would like me to try. All I can say for sure is that oblong's .dll does not exhibit this behaviour.
I don't think it's a size problem, at least not directly. I'm wondering about the returns inside the text, though. I don't use bios, so it was a bit hard for me to imagine what others might be using, and I didn't test for every possible combination.
However, that should be enough for me to fix it. As it's already Sunday, give me a few days.
-
I posted version 1.2.1 on my website.
It turns out the error had nothing to do with the string or the size, but rather how the padding block was treated when a temp file was needed due to large comments being added.
let me know if anything else comes up.
-
Now, I've a feeling that the download link on your page has not been updated. I've flushed my cache just in case, and also tried using a different browser.
The downloaded file claims to be v1.2.0.0, is still giving errors, and has the same crc checksum as the file that is v1.2
The links appeared to be correct, but the file may not have transferred correctly to the server. In any case, I've refreshed the links and re-uploaded the file to the server, so it should now work.
-
I just wanted to pop in and say a HUGE THANKS to scthom for working on this and keeping the FLAC thing going. I'm installing and testing, and will try to help as best I can.
(annual flac rant): The lack of JRiver official support for Flac is one of my biggest annoyances with one of the best pieces of software out there. scthom's effort is fantastic, but JRiver: there is really no excuse not to eventually make flac support INCORPORATED into new MC builds, just like every other popular format: MPC, Wavpack, etc etc.
You will get more customers. Think about it: people want to install the software and start playing whatever tunes they may have -- not start trawling through these forums to see what's available. Flac is too mainstream to be relegated to a plug-in. (end of annual flac rant, sorry).
:-X
-
I'm still getting tagging errors when trying to get that fleetwood mac bios into the file though.
I ripped a queen album to get some fresh files to work with, and they produce the same errors.
I notice the version number does not display in the plugin manager window, but viewing the .dll files properties via windows confirms the 1.2.1 version number.
Another observation, I'm not sure how relevant it is, but, for other filetypes, the bios tag in the action window>file type info window shows "<too large to display>" whereas the flac files that do contain the tag attempt to diplay them.
Hmm. I used the text from your link, and it worked fine on my computer, although I used the "Lyrics" field because I don't have a "Bios" field. "Bios" doesn't appear to be a standard field name for MC? If you don't mind, would you try Lyrics or another long-string field and see what happens (just to be sure)? Also, how is your field set up?
I'll have to work on the <too long to display> thing, although I did do something similar for "Lyrics" while I was in there.
I may have forgotten to update the registry with the new version number, so don't worry about the plugin manager window. If the windows properties says 1.2.1 it's the right one.
I'll take another look when I get home this evening.
-
Marko,
I'm still unable to replicate your errors. I tried adding a "Bios" field, downloaded aTagger and filled it with a long string. It works fine here. I suppose it's possible there is something in the text - an odd character or similar - that is confounding the plugin (I used a different song). But, when I used the text from your site, it worked fine here as well.
I did add the <Too Long To Display> feature, but haven't released anything as of yet.
-
Thanks, Marko.
Given that the errors are only flac files, it definitely points to my decoder plugin. If possible, could you try using the command line flac interface (metaflac) to see what happens when you add the same text? And then see what happens in MC afterwards.
Getting two errors from MC is probably normal. I've noticed that if it fails once, it will usually try again to make sure. After the 2nd time is when it gives the user error message.
I'll keep trying here on my end to see if I can throw it off somewhere. I'll also put the debug version of the decoder plugin on the website -- it makes log files you can send me that will help.
-
scthom, did you get my email?
Er, no. Not as of yet. Since you sent it over 8 hours ago, I'm thinking I probably won't... :(
-
Hello scthom - First of all, thanks a million for donating your time and coding expertise to provide us poor MC users with a FLAC encoder and decoder. I for one REALLY appreciate it.
I'm having a problem with FLAC files that Matt from JRiver says could be caused by the decoder. Whenever I attempt to burn a CD from FLAC files with MC v11.0.314, MC will only burn a few seconds from a few random tracks in my burn list. It then ejects the CD. This happens every time. It doesn't matter what track selections I make, what my drive settings are, etc. It's perfectly repeatable but it ONLY happens when I'm trying to burn CDs from FLAC files. Burning from any other file format (APE, MP3, WAV, etc.) works fine. Other MC users are having the same problem.
Matt seems to think it's possible that your encoder may not be handing of file sizes to MC correctly. Is this something you could look into?
Here's the thread in the Media Center Forum that sparked the issue:
http://yabb.jriver.com/interact/index.php?topic=29282.0
-
Yes, there seems to be a problem with burning audio CDs. I tried it now. MC went through the burn process in few seconds and made a CD with 5 to 6 second long tracks. (MC 11.0.314 and in_flac v. 1.21).
I also noticed that sometimes (or all the time?) MC can write tags, but not actually read them. I made a short sample file if you like to try it: TestSample.flac (http://kotisivu.mtv3.fi/alexb/pix/TestSample.flac). All other FLAC-aware applications I have can read the tags normally.
-
For the record, I'm also having tagging issues with FLAC files since installing the newest plug-in. I get errors saying MC couldn't write to the file but the database gets updated anyway. I can only assume the tag has not been written but MC managed to update its own database.
Is this fixable?
-
Yes, there seems to be a problem with burning audio CDs. I tried it now. MC went through the burn process in few seconds and made a CD with 5 to 6 second long tracks. (MC 11.0.314 and in_flac v. 1.21).
The first thing MC does when doing a burn is send a DoCommand(5, 2, 0) to the InputSource interface. Later on it sends a GetInformation(15, xxx). Matt/JRiver - what do these do? They're not documented in the SDK - the DoCommand enum only has entries up to 4 and GetInformation only goes up to 11.
(rhetorical) How am I supposed to write a plugin that works if the SDK isn't kept up-to-date?
-
There is a new version of the decoder (v1.2.2) posted on my website, http://members.cox.net/scot.thompson. The tagging bug appears to be fixed (thanks to Marko for testing).
The CD burn bug is not yet fixed. I'm awaiting info from JRiver. MC appears to be closing the InputSource interface after 56 frames are decode (5.6 seconds, normally). There are some gaps in the SDK that may or may not be the cause.
Since the InputSource interface is used for both playback and burning, and playback seems to be working fine, I'm not sure as of yet where to start looking. Will keep everyone informed as it gets fixed.
-
scthom - Any word yet from JRiver on this?
-
Hi Scthom.
An updated input plugin SDK is coming soon. (today hopefully)
Are you using a JRiver reader in your code? If so, it makes things a little more complicated because v11 and v11.1 use different reader interfaces. Let us know so we can figure out how to proceed. Feel free to drop me an email. (matt at jriver dot com)
Thanks,
-Matt
-
scthom I just had to say THANK YOU for the FLAC support!! I have encoded 1041 albums with the .flac encoder and a total of 12195 tracks...without the encoder support from oblong and yourself I would have never been able to archive my CD collection..thanks!
*And yes I received alot of flac while encoding albums over 6 weeks from the wife ;)
-
I believe the CD Burn problem in the decoder is fixed. It was a relatively minor bug due to the Length in Blocks not being set. The testing that I did worked, so please let me know if you still have problems. Everybody say thanks to Matt for helping with the SDK and pointing out the length variable.
Version 1.2.3 is now posted.
http://members.cox.net/scot.thompson
-
It works!! Awesome! I've just burned half a dozen CD-Rs with zero problems. Thanks a MILLION Scot (and Matt).
-
I still can't save tags.
I uninstalled the old decoder (and encoder just to be safe) and installed the latest versions. I registered them via MC as well. If I attempt to change a tag I get the same error message from MC saying it couldn't update the file.
Anything I can try to help shed some light on this?
-
confirmed.
v1.2.2 fixed all the tagging issues I'd encountered.
v1.2.3 appears to have broken down completely as it does not show any info at all in the taf info window.
Reverting back to v1.2.2 sorted the tagging and display problems.
-
v1.2.3 tagging works fine with MC v11.1.028 alpha. It does not work with v11.0.316. Scot must have made changes based on the new MC 11.1 SDK.
-
v1.2.3 tagging works fine with MC v11.1.028 alpha. It does not work with v11.0.316. Scot must have made changes based on the new MC 11.1 SDK.
I was just going to add that :)
I'll keep v1.2.2 for use with v11.
-
Interesting. I'm not using 11.1 here, I stayed with 11.0.316. And it seemed to work fine for me, so I don't think it's an 11.1 issue. I'll have more time later this week to try to investigate.
-
That is interesting Scot. I can tell you that when using the v1.2.3 encoder and MC v11.1.028 Alpha to convert APE to FLAC I had no problems at all with tagging. When I reverted back to MC v11.0.316 performing the same conversion operation resulted in tagging errors on every single file. I had installed v11.0.316 over my existing v11.1.028 without uninstalling the Alpha first, but I did re-install your FLAC plugins via the MC Plug-in Manager after doing so.
-
FWIW, mc11.1 has never been installed on this machine. playback still works just fine, it appears to be just the tagging that's broken, both the application of, and the reporting via the filetype info action window.
I'll try some more controlled testing later this evening.
-
I also noticed that sometimes (or all the time?) MC can write tags, but not actually read them. I made a short sample file if you like to try it: TestSample.flac (http://kotisivu.mtv3.fi/alexb/pix/TestSample.flac). All other FLAC-aware applications I have can read the tags normally.
scthom, did you try this sample file?
1.21 and 1.23 cannot read the file tags on my PC (MC11.0.314). I haven't tried 1.22.
-
OK, I tested a few things pretty quick. I have good news and bad news.
The good news is I figured out what the problem is. The SDK that Matt updated contains portions (specifically JRReader.lib) that must be from 11.1. I mis-spoke when I said in previous posts that it worked fine here on 11.0.316 -- the FileInfo interface was broken due to the 11.0/11.1 changes. That's the bit that does the File Type Info and Tagging. The InputSource interface that does the decoding seems to work fine because I didn't use the Reader there.
The bad news is only that it will take a bit of time to work out. I'll have to go to the registry to figure out which version is installed and use the right Open() functions from the Reader. Give me a few days (sorry!) due to the day job being a bit crazy right now.
-
Dude, take it easy on yourself! ;D Whenever you get the time to take care of it is fine. It's not the end of the world.
-
So, if I upgrade to MC 11.1 the current plug-in will write tags?
-
The v1.2.3 encoder will handle tags properly with MC v11.1, and it fixes the CD burning from FLAC files problem as well. If you're using MC v11.0.xxx then you'll have to use v1.2.2 of the FLAC encoder to handle tags properly. v1.2.2 has the CD burning porblem however and will not burn CDs from FLAC files properly.
-
Where can I download the 1.2.2 encoder? Scthom's site only has the 1.2.3 version available.
-
I've posted decoder version 1.3.0 on my website -- I think it fixes the version incompatibility problems with 11.0 and/or 11.1. And it should still fix the long tag and CD burn bugs.
As usual, please let me know if you find anything.
http://members.cox.net/scot.thompson
All I was using the JRReader for was to get the file size, so I got it another way. I should be able to maintain compatibility with both versions for now.
-
That did it!
Thank you so VERY much!!
-
One follow-up question:
I added about 300 files to my music library while I was unable to write to FLAC tags. MC stored any data I entered in its library but now that the plug-in is working I'd like to force MC to write this data to the FLAC tag. Is there some way to do that?
Thanks!
-
select them all, right click, library tools>update tags fron library ought to do it.
perhaps try one or two first just to check.
-
Scot - The link on your webpage still identifies the decoder plugin as v1.2.3. Is that correct?
-
Scot - The link on your webpage still identifies the decoder plugin as v1.2.3. Is that correct?
It is just the text on the webpage. Also the About button inside the Plug-in Manager shows still v.1.2.3.
The plug-in itself is 1.3.0 and tag reading & tagging works nicely with MC 11.0.314 and 11.1.30.
-
Glad to hear it's working. If anybody comes across any bugs, please let me know.
-
Thanks, scthom, for your patience and hard work.
-
I'll second that. Thanks a lot for making FLAC a viable lossless format for MC users Scot. Your hard work is appreciated.
-
Absolutely...thank you for all your efforts. I literally use your plug-ins every day. That's pretty cool to be able to help so many people.
-
Is the FLAC decoder supposed to work with Library Server?
I'm running MC 11.0.316 on both an XP server and a Win2K client. The client plays my mp3 files from the server fine, but it won't play FLAC. I am using version 1.3.0 of the FLAC Decoder plug-in.
-
That's a good question. I haven't used Library Server, so I can't say (I only have the one computer for music). I'm interested to see what others have tried and/or found out.
-
How can I tell if I've got the latest plug-in?
-
How can I tell if I've got the latest plug-in?
One Easy way -- use Windows Explorer and hover over the plugin DLL or view it as a tile. The version number is part of the properties.
Another Easy Way -- From MC Plug-in Manager, Click "About" for the decoder (Input). For the Encoders, it's on the main plugin-description page in the Plug-in Manager.
-
One Easy way -- use Windows Explorer and hover over the plugin DLL or view it as a tile. The version number is part of the properties.
Another Easy Way -- From MC Plug-in Manager, Click "About" for the decoder (Input). For the Encoders, it's on the main plugin-description page in the Plug-in Manager.
Thanks!