Topic: Announce: FLAC Plugin Set (Read 41551 times)

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/.
[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.

Alex B · « **Reply #1 on:** August 13, 2005, 06:14:56 am »

Great! Excellent work again.

My notes:

Quote

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).

Quote

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.

jgreen · « **Reply #2 on:** August 13, 2005, 09:51:44 am »

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

jgreen · « **Reply #3 on:** August 13, 2005, 10:17:19 am »

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.

jgreen · « **Reply #4 on:** August 13, 2005, 10:54:24 am »

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.

jgreen · « **Reply #5 on:** August 13, 2005, 11:07:48 am »

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.

jgreen · « **Reply #6 on:** August 13, 2005, 11:37:56 am »

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.

jgreen · « **Reply #7 on:** August 13, 2005, 12:15:02 pm »

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.

scthom · « **Reply #8 on:** August 13, 2005, 12:28:18 pm »

Quote from: Alex B on August 13, 2005, 06:14:56 am

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.

Quote from: jgreen on August 13, 2005, 09:51:44 am

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.

Quote from: jgreen on August 13, 2005, 11:07:48 am

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

Quote from: jgreen on August 13, 2005, 12:15:02 pm

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).

jgreen · « **Reply #9 on:** August 13, 2005, 12:39:35 pm »

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?

scthom · « **Reply #10 on:** August 13, 2005, 12:46:08 pm »

Quote from: jgreen on August 13, 2005, 12:39:35 pm

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

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.

jgreen · « **Reply #11 on:** August 13, 2005, 12:49:53 pm »

Don't I have to install the decoder to experience problems with it?

scthom · « **Reply #12 on:** August 13, 2005, 12:52:45 pm »

Quote from: jgreen on August 13, 2005, 12:49:53 pm

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.

Alex B · « **Reply #13 on:** August 13, 2005, 04:21:47 pm »

Quote from: scthom on August 13, 2005, 12:28:18 pm

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!

jgreen · « **Reply #14 on:** August 13, 2005, 04:36:44 pm »

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.

indybrett · « **Reply #15 on:** August 13, 2005, 07:23:55 pm »

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.

scthom · « **Reply #16 on:** August 13, 2005, 08:35:29 pm »

Quote from: Alex B on August 13, 2005, 04:21:47 pm

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

scthom · « **Reply #17 on:** August 14, 2005, 12:55:03 pm »

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.

scthom · « **Reply #18 on:** August 23, 2005, 11:52:54 pm »

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.

jgreen · « **Reply #19 on:** August 24, 2005, 12:31:41 am »

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.

scthom · « **Reply #20 on:** August 24, 2005, 09:12:10 pm »

Quote from: jgreen on August 24, 2005, 12:31:41 am

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).

iCamp · « **Reply #21 on:** August 26, 2005, 01:09:12 pm »

scthom,

I just wanted to say 'thank you'. Your hard work is very much appreciated.

scthom · « **Reply #22 on:** September 10, 2005, 11:34:10 am »

Quote from: marko on September 09, 2005, 06:27:40 pm

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.

jgreen · « **Reply #23 on:** September 10, 2005, 12:03:12 pm »

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.

scthom · « **Reply #24 on:** September 11, 2005, 04:48:44 pm »

Quote from: marko on September 11, 2005, 02:31:26 pm

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.

scthom · « **Reply #25 on:** September 12, 2005, 11:53:22 pm »

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.

scthom · « **Reply #26 on:** September 13, 2005, 08:50:26 pm »

Quote from: marko on September 13, 2005, 02:06:54 am

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.

stefansmith · « **Reply #27 on:** September 14, 2005, 12:14:53 am »

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).

scthom · « **Reply #28 on:** September 14, 2005, 04:44:30 pm »

Quote from: marko on September 14, 2005, 03:27:00 am

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.

scthom · « **Reply #29 on:** September 14, 2005, 11:17:52 pm »

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.

scthom · « **Reply #30 on:** September 16, 2005, 06:48:32 pm »

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 · « **Reply #31 on:** September 20, 2005, 08:39:32 pm »

Quote from: marko on September 20, 2005, 11:56:47 am

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...

dpippel · « **Reply #32 on:** September 22, 2005, 08:45:42 am »

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

Alex B · « **Reply #33 on:** September 24, 2005, 10:43:53 am »

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. All other FLAC-aware applications I have can read the tags normally.

iCamp · « **Reply #34 on:** September 24, 2005, 11:05:31 am »

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?

scthom · « **Reply #35 on:** September 25, 2005, 12:21:28 pm »

Quote from: Alex B on September 24, 2005, 10:43:53 am

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?

scthom · « **Reply #36 on:** September 25, 2005, 04:45:06 pm »

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.

dpippel · « **Reply #37 on:** September 28, 2005, 07:59:19 am »

scthom - Any word yet from JRiver on this?

Matt · « **Reply #38 on:** September 28, 2005, 10:19:56 am »

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

ripper99 · « **Reply #39 on:** September 29, 2005, 01:14:46 pm »

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

scthom · « **Reply #40 on:** September 29, 2005, 11:15:45 pm »

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

dpippel · « **Reply #41 on:** September 30, 2005, 08:51:14 am »

It works!! Awesome! I've just burned half a dozen CD-Rs with zero problems. Thanks a MILLION Scot (and Matt).

iCamp · « **Reply #42 on:** September 30, 2005, 09:35:04 pm »

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?

marko · « **Reply #43 on:** October 01, 2005, 02:05:57 am »

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.

dpippel · « **Reply #44 on:** October 02, 2005, 08:31:37 am »

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.

marko · « **Reply #45 on:** October 02, 2005, 10:54:22 am »

Quote from: dpippel on October 02, 2005, 08:31:37 am

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.

scthom · « **Reply #46 on:** October 03, 2005, 09:09:19 pm »

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.

dpippel · « **Reply #47 on:** October 04, 2005, 09:08:08 am »

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.

marko · « **Reply #48 on:** October 04, 2005, 09:40:06 am »

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.

Alex B · « **Reply #49 on:** October 04, 2005, 10:00:26 am »

Quote from: Alex B on September 24, 2005, 10:43:53 am

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. 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.

INTERACT FORUM

Author Topic: Announce: FLAC Plugin Set (Read 41551 times)